🥇Списък за готовност за производство

Преводът на статията е подготвен специално за студентите в курса „DevOps практики и инструменти“, който стартира вече днес!

Някога пуснали ли сте нова услуга в продукция? Или може би сте работили по поддръжката на такива услуги? Ако да, какво ръководеше вашите решения? Какво е добро, а какво е лошо за продукция? Как обучавате новите членове на екипа за релизите или for поддръжката на съществуващи услуги?

Повечето компании в частта на практиките за производствена експлоатация в крайна сметка преминават към подходи 'Дивия Запад'. Всеки екип самостоятелно определя инструментите и най-добрите практики чрез проби и грешки. Но това често влияе не само на успеха на проектите, но и на инженерите.

Методът на пробите и грешките създава среда, в която е разпространено търсенето на виновни и прехвърляне на отговорността. При такова поведение става все по-трудно да се учим от грешките и да не ги повтаряме.

Успешните организации:

осъзнават необходимостта от ръководства за продукция,
изучават най-добрите практики,
започват обсъждане на въпросите за готовността на продукцията при разработването на нови системи или компоненти,
осигуряват спазването на правилата за подготовка за продукция.

Подготовката за продукция включва процес на 'ревю'. Ревюто може да бъде под формата на контролен списък или набор от въпроси. Ревютата могат да се извършват ръчно, автоматично или по двата начина. Вместо статични списъци с изисквания могат да се направят шаблони на контролни списъци, които да се адаптират към специфичните нужди. По този начин инженерите могат да получат начин да наследяват знания и достатъчна гъвкавост, когато е необходимо.

Кога да проверите услугата за готовност за продукция?

Полезно е да се извършва проверка на готовността за продукция не само непосредствено преди релиза, но и при предаване на услугата на друг екип за експлоатация или на нов служител.

Извършете проверка, когато:

Пуснете нова услуга в продукция.
Предадете експлоатацията на продукционна услуга на друг екип, като SRE.
Предадете експлоатацията на продукционна услуга на нови служители.
Организирате техническа поддръжка.

Контролен списък за проверка на готовността за продукция

Преди време, като пример, аз публикува контролен списък за проверка на готовността за продукция. Въпреки че този списък възникна при работа с клиенти на Google Cloud, той ще бъде полезен и приложим извън Google Cloud.

Проектиране и разработка

Разработете възпроизведим процес на изграждане, който не изисква достъп до външни услуги и не зависи от провала на външни системи.
По време на проектирането и разработката определете и установете SLO за вашите услуги.
Документирайте очакванията относно достъпността на външните услуги, от които зависите.
Избягвайте единична точка на отказ, премахвайки зависимостите от един глобален ресурс. Репликирайте ресурса или използвайте резервен вариант, когато ресурсът не е наличен (например, твърдо кодирана стойност).

Управление на конфигурацията

Статичната, малка и несекретна конфигурация може да бъде предавана чрез параметри на командния ред. За всичко останало използвайте услуги за съхранение на конфигурации.
Динамичната конфигурация трябва да има резервни настройки в случай на недостъпност на услугата за конфигурация.
Конфигурацията на средата за разработка не трябва да бъде свързана с конфигурацията на продукцията. Иначе това може да доведе до достъп от средата за разработка до услугите на продукцията, което може да причини проблеми с поверителността и изтичане на данни.
Документирайте какво може да бъде настроено динамично и опишете резервното поведение, ако системата за доставка на конфигурация стане недостъпна.

Управление на релизите

Подробно документирайте процеса на релиз. Опишете как релизите влияят на SLO (например, временно увеличение на закъснението поради пропуски в кеша).
Документирайте канарените релизи.
Разработете план за анализ на канарените релизи и, ако е възможно, механизми за автоматично откат.
Уверете се, че откатите могат да използват същите процеси, каквито и разгръщането.

Пригодност за мониторинг (Observability)

Уверете се, че се събира набор от метрики, необходими за SLO.
Уверете се, че можете да различавате клиентските и сървърните данни. Това е важно за откриването на причините за неизправности.
Настройте оповестявания, за да намалите трудозатратата. Например, премахнете оповестяванията, предизвикани от рутинни операции.
Ако използвате Stackdriver, включете метриките на платформата GCP в своите табла. Настройте оповестявания за GCP-зависимости.
Винаги разпространявайте входящата трасировка. Дори ако не участвате в трасировката, това ще позволи на по-ниските нива на услуги да отстраняват проблеми в продукцията.

Защита и сигурност

Убедете се, че всички външни връзки са криптирани.
Убедете се, че вашите производствени проекти имат правилна настройка на IAM.
Използвайте мрежи за изолиране на групи от виртуални машини.
Използвайте VPN за безопасно свързване с отдалечени мрежи.
Документирайте и наблюдавайте достъпа на потребителите до данните. Убедете се, че целият достъп на потребителите до данните се проверява и регистрира.
Убедете се, че крайните точки за отстраняване на грешки са ограничени с ACL.
Валидирайте потребителския вход. Настройте ограничения за размера на полезната информация за потребителския вход.
Убедете се, че вашата услуга може селективно да блокира входящия трафик за отделни потребители. Това ще позволи блокиране на нарушения, без да засяга други потребители.
Избягвайте външни крайни точки, които инициират голям брой вътрешни операции.

Планиране на капацитети

Документирайте как се мащабира вашата услуга. Например: брой потребители, размер на входящото натоварване, брой входящи съобщения.
Документирайте изискванията за ресурси за вашата услуга. Например: брой извлечени виртуални машини, брой инстанции на Spanner, специализирано оборудване като GPU или TPU.
Документирайте ограниченията на ресурсите: вид ресурс, регион и т.н.
Документирайте ограниченията на квотите за създаване на нови ресурси. Например, ограничение на броя заявки за GCE API, ако използвате API за създаване на нови инстанции.
Разгледайте възможността за провеждане на натоварващи тестове за анализ на спад в производителността.

Това е всичко. До виждане на занятията!

Източник: habr.com