Джин Ким - Руководство по DevOps

На первый взгляд эти требования похожи на традиционные контрольные перечни, использованные ранее. Однако ключевое различие в том, что требуется наличие эффективного мониторинга, процесс развертывания должен быть четким и надежным, а архитектура — поддерживать быстрое и частое внедрение кода.

Если во время оценки найдены недостатки, инженер эксплуатации должен помочь команде разработчиков решить проблемы и при необходимости даже перепроектировать продукт, чтобы его было легко развернуть и сопровождать.

Возможно, на этом этапе стоит проверить, соответствует ли наш сервис нормативным требованиям или должен ли он будет соответствовать в будущем.

• Приносит ли продукт достаточно дохода (например, если доход составляет более 5 % общего дохода открытого акционерного общества компании в США, он считается «значительной частью» и подлежит регулированию в соответствии с разделом 404 Акта Сарбейнза — Оксли [130](SOX) 2002 г.)?

• Высок ли у приложения пользовательский трафик? Высокая ли у него цена простоя? Например, могут ли проблемы эксплуатации повлечь за собой репутационные издержки или риски доступности?

• Хранит ли сервис информацию о владельцах платежных карт, например номера таких карт, или какую-либо личную информацию, например номера социального страхования или записи о лечении пациентов? Есть ли проблемы с безопасностью, влекущие за собой нормативные, репутационные риски, риски по выполнению контрактных обязательств или по нарушению права на сохранение личной информации?

• Есть ли у сервиса какие-нибудь другие нормативные или контрактные обязательства, например в связи с правилами экспорта, стандартами безопасности данных индустрии платежных карт (PCI-DSS), законом об ответственности и переносе данных о страховании здоровья граждан (HIPAA)?

Рис. 38. Service Handback (Передача управления приложением), Google (источник: «SRE@Google: Thousands of DevOps Since 2004», видео с сайта YouTube, 45:57, выложено пользователем USENIX, 12 января 2012 г., https://www.youtube.com/watch?v=iIuTnhdTzK0)

Эта информация поможет проверить, что мы управляем не только техническими рисками, связанными с нашим продуктом, но также и потенциальными рисками, связанными с нормативным регулированием и обеспечением безопасности. Подобные соображения также будут полезными при проектировании среды контроля над производством продукции.

Благодаря встраиванию требований к эксплуатации в ранние стадии процесса разработки и переносу ответственности за первоначальное сопровождение приложений на разработчиков процесс внедрения новых продуктов становится более гладким, простым и предсказуемым. Однако, если сервис уже находится в эксплуатации, нужен другой механизм, чтобы отдел эксплуатации не оказался один на один с неподдерживаемым приложением. Это особенно важно для функционально ориентированных организаций.

В этом случае можно создать механизм возвращения сервиса разработчикам . Другими словами, когда продукт становится достаточно неустойчивым, у эксплуатации есть возможность вернуть ответственность за его поддержку обратно разработчикам.

Когда сервис переходит под крыло разработчиков, роль отдела эксплуатации меняется на консультационную: теперь они помогают команде снова сделать продукт готовым к эксплуатации.

Этот механизм служит подобием парового клапана, чтобы инженеры эксплуатации никогда не оказывались в такой ситуации, что им нужно поддерживать нестабильно работающее приложение, в то время как все увеличивающееся количество долгов погребает их с головой и локальные проблемы превращаются в одну глобальную. Эта методика также гарантирует, что у эксплуатации всегда есть время на улучшение и оптимизацию работы и на разные профилактические меры.

Механизм возврата — одна из практик-долгожительниц компании Google и, пожалуй, отличный способ показать взаимное уважение между инженерами разработки и эксплуатации. С его помощью разработчики могут быстро создавать новые сервисы, а отдел эксплуатации может подключаться, когда продукты становятся стратегически важными для компании, и в редких случаях возвращать их обратно, когда поддерживать становится слишком проблематично [131]. Следующий пример из практики подразделения по обеспечению стабильности сайтов компании Google показывает, как эволюционировали проверки на готовность к смене сопроводителя и на готовность к запуску и какую пользу это принесло.