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

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

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

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

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

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

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

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

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

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

Правете проверка, когато:

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

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

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

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

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

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

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

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

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

Подходящост за наблюдение (Observability)

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

Защита и безопасност

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

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

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

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

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