Контролен лист за готовност за производство

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

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

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

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

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

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

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

Кога да проверим сервиз за готовност за производство?

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

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

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

Контролен лист за готовност за производство

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

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

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

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

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

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

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

Наблюдаемост

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

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

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

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

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

Това е всичко. Ще се видим в клас!

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