Відповідайте за сервіс після розгортання

Визначте сервіс, від якого залежать користувачі

Розгортання робить програмне забезпечення доступним. Експлуатація зберігає його корисність зі змінами користувачів, залежностей, трафіку та вимог. Генератор коду не усуває цієї постійної роботи.

Для вигаданого експорту даних клієнтів користувачам потрібно більше, ніж доступна сторінка. Їм потрібні дозволені записи в потрібному форматі за прийнятний час. Також сервіс має запобігати доступу до даних іншої організації.

Назвіть відповідального до випуску. Запишіть, хто реагує поза звичайними робочими годинами, якщо це входить до зобов’язань сервісу. Постачальник може виконувати частину роботи, але організація все ще потребує чіткого порядку ухвалення рішень і комунікації.

Виберіть сигнали, що допомагають діяти

Показник рівня сервісу, або SLI, вимірює визначену властивість поведінки сервісу. Цільовий рівень сервісу, або SLO, установлює ціль для цього показника за зазначений період. Вибирайте ціль на основі потреб користувачів і можливостей експлуатації.

Рекомендації Google SRE пояснюють цей підхід і використання бюджету помилок у рішеннях щодо надійності. Не копіюйте ціль іншого сервісу без перевірки її змісту. Рекомендації щодо SLO, приклад політики бюджету помилок.

Для експорту визначте, що вважається успішним запитом, який має право на виконання. Відокремте очікувані відмови в доступі від системних збоїв. Документуйте виключення, щоб метрика не могла поліпшитися лише через приховування складних запитів.

Не записуйте повний експорт у журнали для поліпшення видимості. Збирайте мінімальну інформацію, потрібну для діагностики проблеми, і захищайте доступ до неї.

Підготуйте реагування на інциденти

Визначте, хто координує, хто розслідує та хто комунікує. У малій команді ці ролі можна поєднати, але обов’язки мають залишатися чіткими. Ведіть записи спостережень і дій.

Рекомендації Google щодо реагування на інциденти наголошують на координації й комунікації поряд із технічним зменшенням впливу. Технічно правильне виправлення все ще може залишити користувачів непоінформованими або кількох учасників реагування — із суперечливими змінами. Реагування на інциденти.

Агент може узагальнювати журнали або порівнювати гіпотези в межах схваленої обробки даних. Він не має отримувати необмежених повноважень у продуктивному середовищі через терміновість інциденту. Для виняткового доступу використовуйте визначений порядок ескалації.

Відпрацьовуйте відновлення та фінансуйте обслуговування

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

Призначте постійну роботу: оновлення залежностей, перегляди доступу, поновлення сертифікатів, де потрібно, зміни потужності та виправлення документації. Сервіс без ресурсів на обслуговування накопичує обов’язки після завершення бюджету запуску.

Після інциденту виберіть поліпшення, що усувають спостережувані причини. Пов’яжіть їх із реалізацією та перевіркою. Так замикається життєвий цикл: операційні докази змінюють те, що команда специфікує та створює далі.