Перевод статьи подготовлен специально для студентов курса.
«Практики и инструменты DevOps» 
Вы когда-нибудь запускали в производство новый сервис? Или, может быть, вы занимались поддержкой таких сервисов? Если да, что вас мотивировало? Что хорошо для производства, а что плохо? Как вы обучаете новых членов команды выпускам или обслуживанию существующих сервисов?
Большинство компаний в конечном итоге перенимают подходы «Дикого Запада», когда дело доходит до практики производственных операций.
Каждая команда методом проб и ошибок самостоятельно определяет инструменты и лучшие практики.
Но это зачастую влияет не только на успех проектов, но и на инженеров.
Метод проб и ошибок создает среду, в которой обычное дело – указывать пальцем и перекладывать вину.
При таком поведении становится все труднее учиться на ошибках и не повторять их снова.
Успешные организации:
осознать необходимость руководящих принципов производства, изучить лучшие практики, начать обсуждение вопросов готовности производства при разработке новых систем или компонентов, обеспечить соблюдение правил подготовки производства.Подготовка к производству включает в себя процесс «проверки».
Обзор может быть в форме контрольного списка или набора вопросов.
Проверка может выполняться вручную, автоматически или и то, и другое.
Вместо статических списков требований вы можете создавать шаблоны контрольных списков, которые можно адаптировать под конкретные нужды.
Таким образом, инженерам будет предоставлена возможность унаследовать знания и достаточная гибкость, когда это необходимо.
Когда проверять сервис на готовность к производству?
Проверку готовности производства полезно проводить не только непосредственно перед выпуском, но и при передаче его другой эксплуатационной команде или новому сотруднику.Проверьте, когда: Вы запускаете в производство новый сервис.
Вы передаете работу продакшн-службы другой команде, например SRE. Вы передаете работу производственной службы новым сотрудникам.
Организовать техническую поддержку.
Контрольный список готовности производства
Некоторое время назад, например, я опубликовано чек-лист для проверки готовности к производству.
Хотя этот список составлен клиентами Google Cloud, он будет полезен и применим за пределами Google Cloud.
Дизайн и развитие
Разработайте повторяемый процесс сборки, не требующий доступа к внешним сервисам и не зависящий от сбоя внешних систем.На этапе проектирования и разработки определите и установите SLO для ваших услуг.
Задокументируйте ожидания относительно доступности внешних услуг, от которых вы зависите.
Избегайте единой точки отказа, удалив зависимости от одного глобального ресурса.
Реплицируйте ресурс или используйте резервный вариант, когда ресурс недоступен (например, жестко запрограммированное значение).
Управление конфигурацией
Статическую, небольшую и несекретную конфигурацию можно передать через параметры командной строки.Для всего остального используйте сервисы хранения конфигурации.
Динамическая конфигурация должна иметь резервные настройки на случай, если служба конфигурации будет недоступна.
Конфигурация среды разработки не должна быть связана с производственной конфигурацией.
В противном случае это может привести к доступу из среды разработки к производственным сервисам, что может вызвать проблемы с конфиденциальностью и утечку данных.
Задокументируйте, что можно настроить динамически, и опишите резервное поведение, если система доставки конфигурации недоступна.
Управление релизами
Подробно документируйте процесс выпуска.Опишите, как выпуски влияют на SLO (например, временное увеличение задержки из-за промахов в кэше).
Документируйте канареечные релизы.
Разработайте канареечный план проверки выпуска и, если возможно, механизмы автоматического отката.
Убедитесь, что при откате могут использоваться те же процессы, что и при развертывании.
Наблюдаемость
Убедитесь, что собран набор метрик, необходимых для SLO. Убедитесь, что вы можете различать данные клиента и сервера.Это важно для поиска причин неисправностей.
Настройте оповещения, чтобы сократить трудозатраты.
Например, удалить оповещения, вызванные рутинными операциями.
Если вы используете Stackdriver, включите метрики платформы GCP в свои информационные панели.
Настройте оповещения о зависимостях GCP. Всегда распространяйте входящие трассировки.
Даже если вы не участвуете в отслеживании, это позволит службам более низкого уровня отлаживать проблемы в рабочей среде.
Защита и безопасность
Убедитесь, что все внешние соединения зашифрованы.Убедитесь, что в ваших производственных проектах правильно настроен IAM. Используйте сети для изоляции групп экземпляров виртуальных машин.
Используйте VPN для безопасного подключения к удаленным сетям.
Документируйте и контролируйте доступ пользователей к данным.
Убедитесь, что весь доступ пользователей к данным контролируется и регистрируется.
Убедитесь, что конечные точки отладки ограничены списками управления доступом.
Очистите ввод пользователя.
Настройте ограничения размера полезной нагрузки для пользовательского ввода.
Убедитесь, что ваш сервис может выборочно блокировать входящий трафик для отдельных пользователей.
Это позволит заблокировать нарушения, не затрагивая других пользователей.
Избегайте внешних конечных точек, которые инициируют множество внутренних операций.
Планирование мощностей
Документируйте, как масштабируется ваш сервис.Например: количество пользователей, размер входящей полезной нагрузки, количество входящих сообщений.
Задокументируйте требования к ресурсам для вашего сервиса.
Например: количество выделенных экземпляров виртуальных машин, количество экземпляров Spanner, специализированное оборудование, такое как графический процессор или TPU. Ограничения ресурсов документа: тип ресурса, регион и т. д. Документируйте ограничения квот для создания новых ресурсов.
Например, ограничение количества запросов к API GCE, если вы используете API для создания новых экземпляров.
Рассмотрите возможность запуска нагрузочных тестов для анализа снижения производительности.
Вот и все.
Увидимся в классе ! Теги: #DevOps #контрольный список
-
О Вопросе Стандартизации Спецификаций W3C
19 Oct, 24 -
А: Мертв
19 Oct, 24 -
Странная «Фишка» В Почте Mail.ru
19 Oct, 24
