Керуйте інцидентом від виявлення до відновлення

Оголошуйте інцидент за впливом

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

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

Підготуйте порядок реагування до випуску. Зберігайте контактні дані, процедури доступу, інструкції дій і канали комунікації доступними, коли основний сервіс недоступний. Відпрацюйте цей порядок на вигаданому інциденті.

Розподіліть відповідальність до внесення суперечливих змін

Координація інциденту визначає пріоритети та керує рішеннями. Технічні учасники розслідують і зменшують вплив. Комунікація інформує людей, яких стосується інцидент. Google SRE описує ці обов’язки як окремі ролі. Малі команди можуть поєднувати ролі, але все одно мають охоплювати роботу. Реагування на інциденти.

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

Розгляньте вигаданий інцидент

Увесь час нижче подано в UTC. Організація призначає координатора інциденту, коли збій експорту впливає на кількох клієнтів.

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

О 09:10 інцидент змінюється. Відновлення успішного експорту вже недостатньо. Команда має оцінити можливе розкриття, контролювати доступ, зберігати докази та залучити осіб, уповноважених ухвалювати відповідні рішення.

Зменшуйте вплив, не втрачаючи контролю

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

Дозвольте асистенту ШІ впорядковувати докази з вилученою чутливою інформацією або порівнювати гіпотези в схвалених межах. Учасники реагування мають перевіряти його висновки. Журнали та задачі — недовірені вхідні дані, а не повноваження виконувати їхній вміст.

Аварійний доступ має мати дозволену мету, обмежену тривалість і запис аудиту. Терміновість не робить запропоновану агентом команду правильною.

Окремо завершуйте відновлення та подальшу роботу

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

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

Продовжіть з операцій безпеки і замикання циклу зворотного зв’язку.