Переклад статті підготовлений спеціально для студентів курсу , Що стартує вже сьогодні!
Ви колись випускали новий сервіс у продакшн? Чи, може, займалися супроводом таких сервісів? Якщо так, то чим ви керувалися? Що для продакшена добре, а що погано? Як ви навчаєте нових учасників команди релізам чи супроводу існуючих сервісів.
Більшість підприємств у частині практик промислової експлуатації в результаті приходять до підходів “Дикого Заходу”. Кожна команда за допомогою проб та помилок самостійно визначається з інструментами та найкращими практиками. Але це часто впливає не лише на успіх проектів, а й на інженерів.
Метод спроб і помилок створює середовище, в якому поширений пошук винних та перекладання відповідальності. За такої поведінки стає все важче вчитися на помилках і не повторювати їх знову.
Успішні організації:
- усвідомлюють необхідність гайдлайнів для продакшену,
- вивчають кращі практики,
- починають обговорення питань готовності до продакшену при розробці нових систем чи компонентів,
- забезпечують дотримання правил підготовки до продакшену.
Підготовка до продакшена включає процес “рев'ю”. Рев'ю може бути у вигляді чекліста чи набору питань. Рев'ю можна робити вручну, автоматично або обома способами. Замість статичних списків вимог можна створити шаблони чеклістів, які адаптувати під конкретні потреби. Таким чином, інженерам можна дати спосіб наслідувати знання та достатню гнучкість, коли це потрібно.
Коли перевіряти сервіс на готовність до продакшену?
Перевірку готовності для продакшена корисно проводити не лише безпосередньо перед релізом, а й під час передачі іншій команді експлуатації або новому співробітнику.
Робіть перевірку, коли:
- Випускаєте новий сервіс у продакшн.
- Передаєте експлуатацію продакшн-сервісу іншій команді, як SRE.
- Передаєте експлуатацію продакшн-сервісу новим співробітникам.
- Організуєте техпідтримку.
Чекліст перевірки готовності до продакшену
Якийсь час тому, як приклад, я чекліст перевірки готовності до продакшену. Незважаючи на те, що цей список з'явився під час роботи з клієнтами Google Cloud, він буде корисним і застосовується за межами Google Cloud.
Проектування і розробка
- Розробте процес відтворення, що не вимагає доступу до зовнішніх сервісів і не залежить від збою зовнішніх систем.
- У період проектування та розробки визначте та встановіть SLO для ваших сервісів.
- Документуйте очікування щодо доступності зовнішніх сервісів, від яких ви залежите.
- Уникайте єдиної точки відмови, прибравши залежність від одного глобального ресурсу. Реплікуйте ресурс або використовуйте резервний варіант, коли ресурс недоступний (наприклад, жорстко закодоване значення).
Управління конфігурацією
- Статичну, невелику та не секретну конфігурацію можна передавати через параметри командного рядка. Для решти всього використовуйте послуги зберігання конфігурації.
- Динамічна конфігурація повинна мати резервні налаштування у разі відсутності сервісу конфігурації.
- Конфігурація середовища розробки має бути пов'язані з конфігурацією продакшена. Інакше це може призвести до доступу з середовища розробки до продакшн-сервісів, що може спричинити проблеми конфіденційності та витоку даних.
- Документуйте те, що може бути налаштовано динамічно, та опишіть резервну поведінку, якщо система доставки конфігурації недоступна.
Управління релізами
- Докладно документуйте процес релізу. Опишіть, як релізи впливають на SLO (наприклад, тимчасове збільшення затримок через промахи кешу).
- Документуйте канаркові релізи.
- Розробіть план аналізу канаркових релізів і, при можливості, механізми автоматичного відкату.
- Переконайтеся, що відкати можуть використовувати ті самі процеси, що розгортання.
Придатність до моніторингу (Observability)
- Переконайтеся, що збирається набір метрик, потрібних для SLO.
- Переконайтеся, що можна відрізнити клієнтські та серверні дані між собою. Це важливо для пошуку причин несправностей.
- Налаштуйте оповіщення, щоб зменшити витрати праці. Наприклад, видаліть оповіщення, викликані рутинними операціями.
- Якщо ви використовуєте Stackdriver, увімкніть метрики платформи GCP у свої дашборди. Налаштуйте оповіщення для GCP-залежностей.
- Завжди розповсюджуйте вхідне трасування. Навіть якщо ви не берете участь у трасуванні, це дозволить сервісам нижчого рівня налагоджувати проблеми у продакшені.
Захист і безпека
- Переконайтеся, що всі зовнішні підключення зашифровано.
- Переконайтеся, що ваші продакшн-проекти мають правильне налаштування IAM.
- Використовуйте мережі для ізоляції груп екземплярів віртуальних машин.
- Використовуйте VPN для безпечного підключення до віддалених мереж.
- Документуйте та моніторуйте доступ користувачів до даних. Переконайтеся, що весь доступ користувачів до даних перевіряється та логується.
- Переконайтеся, що кінцеві точки налагодження обмежені ACL.
- Санітизуйте введення користувача. Налаштуйте обмеження розміру корисного навантаження для введення користувача.
- Переконайтеся, що ваш сервіс може вибірково блокувати трафік для окремих користувачів. Це дозволить блокувати порушення, не впливаючи на інших користувачів.
- Уникайте зовнішніх кінцевих точок, які ініціюють велику кількість внутрішніх операцій.
Планування потужностей
- Документуйте, як масштабується ваш сервіс. Наприклад: кількість користувачів, розмір вхідного корисного навантаження, кількість вхідних повідомлень.
- Документуйте вимоги до ресурсів для вашого сервісу. Наприклад: кількість виділених екземплярів віртуальних машин, кількість екземплярів Spanner, спеціалізоване обладнання, таке як GPU або TPU.
- Документуйте обмеження ресурсів: тип ресурсу, регіон тощо.
- Документуйте обмеження квот для створення нових ресурсів. Наприклад, обмеження кількості запитів GCE API, якщо ви використовуєте API для створення нових інстансів.
- Розгляньте можливість проведення тестів навантаження для аналізу зниження продуктивності.
От і все. До зустрічі на заняттях!
Джерело: habr.com