Інженерний огляд
Genetec Mission Control і керований процес реагування
Інцидент закрито. Чи можете ви сказати, як саме на нього відреагували?
Одна й та сама ситуація на об’єкті може бути оброблена двома різними способами – залежно від того, хто цієї ночі був на зміні.
Досвідчений оператор відкриє потрібну камеру, перевірить суміжну зону, підніме групу, повідомить керівника і зафіксує результат. Менш досвідчений спершу зателефонує, потім шукатиме камери, а один із обов’язкових кроків пропустить – не зі злого наміру, а тому що о третій ночі під тиском людина працює за пам’яттю.
Формально інцидент закритий в обох випадках. Фактично це два різні рівні реакції організації, і різниця між ними не зафіксована ніде.
Для керівника служби безпеки це і є головна нестабільність. Виявлення давно стандартизоване: датчики, камери, аналітика працюють однаково в будь-яку зміну. Реагування не стандартизоване. Його якість – функція від досвіду конкретної людини, а відповідальність за результат лежить на службі загалом.
Спершу – одна ситуація замість п’яти повідомлень
Перед тим як говорити про реакцію, варто зняти шар, який їй заважає.
На великому об’єкті одна подія рідко приходить сама. Спрацювання дверей супроводжується рухом у кадрі, сигналом охоронної системи, реакцією аналітики. Оператор отримує п’ять повідомлень і має сам зрозуміти, що це одна ситуація.
Mission Control виконує цю роботу за заданими правилами: пов’язані події збираються в один інцидент – сутність, у якої є пріоритет, власник, процедура і строк. Кількість тривог перестає дорівнювати кількості ситуацій, що потребують рішення.
Це необхідна умова, але ще не відповідь на питання про нестабільність реакції. Згрупувати події – не означає забезпечити, що з ними зроблять правильні речі.
Де закінчується моніторинг і починається управління
Перехід відбувається в конкретній точці: коли регламент перестає бути документом і стає частиною самого процесу.
У більшості організацій процедура реагування існує окремо від системи – у нормативному документі, у роздрукованій інструкції під склом, у голові досвідченого співробітника. Під час події вона має бути пригадана.
У Mission Control процедура супроводжує обробку інциденту крок за кроком, і наступний крок залежить від відповіді на попередній. Це не електронна версія тексту: коментар до кроку можна зробити обов’язковим, а якщо крок дозволено пропустити – оператор зобов’язаний вказати причину.
Різниця для керівника проста. Раніше він міг знати, що процедура затверджена. Тепер він знає, що вона виконана – і чому саме так, якщо були відхилення.
Час як властивість процедури, а не як звітність
Другий рівень тієї самої ідеї стосується не послідовності дій, а їхньої своєчасності.
Для типу інциденту задається максимальний час реакції та час розв’язання. Для окремого кроку процедури – власний строк виконання. Якщо строк не витримано, система фіксує це як подію і повідомляє кого потрібно: керівника відповідальних, самих відповідальних або обох.
Ключове тут не сповіщення, а те, що відбувається далі. Ці події записуються в журнал дій за інцидентом і працюють як критерій відбору при побудові звіту. Тобто «затримка на етапі перевірки» перестає бути враженням і стає даними, з якими можна працювати.
Одразу варто сказати, чим це не є. Йдеться про спостережуваність процесу, а не про контроль швидкості конкретних людей. Дані показують, де саме процедура зупиняється або розтягується. Чи є це проблемою людини, навчання, формулювання самого кроку або нестачі ресурсу – визначає організація, а не система.
Звідси й формула, до якої зводиться весь цей рівень:
регламент каже, що треба зробити. Керований процес показує, чи це зроблено, коли – і що сталося далі.
Автоматизація, у якої є свідома межа
Наступне питання виникає завжди: якщо система веде процедуру, наскільки далеко варто пустити автоматику.
Для керівника важлива не автоматизація сама по собі. Важливо, щоб межа між дією системи та рішенням людини була проведена свідомо і залишалася під контролем.
У Mission Control ця межа має конкретне місце.
Межа автоматизації
Крок процедури можна налаштувати так, щоб система підтверджувала його самостійно за заданими умовами – і за замовчуванням ця можливість вимкнена.
Тобто рішення про те, які саме кроки більше не потребують людини, ухвалюється окремо для кожного з них, поетапно, а не приймається разом із впровадженням системи.
Це відповідає й на типове заперечення про складність для персоналу: процедура спочатку супроводжує оператора, а автоматизуються тільки ті ділянки, де організація вже впевнена в передбачуваності дії.
Другий бік межі – відповідальність за наступний крок. Інцидент можна переслати додатковим учасникам, зберігши власника, або передати іншому – і тоді змінюється саме власник. Питання «хто зараз відповідає» має відповідь у системі, а не в усній домовленості. Так само вирішується адресність: інцидент іде до тих, хто відповідає за цю територію в цю зміну, з передбаченим резервом.
Коли ситуація вимагає кількох підрозділів одночасно, вона розкладається на пов’язані частини: кожна команда веде свою процедуру, керівник бачить картину цілком, а загальна ситуація вважається розв’язаною тільки тоді, коли завершені всі її частини. Приклад із документації виробника – пожежа на пероні аеропорту, де пожежна команда і служба безпеки працюють паралельно за різними процедурами.
Варто додати, що інцидентом тут вважається не лише надзвичайна подія, а й планова задача, що потребує контролю, – від обслуговування обладнання до перевірки обходу постів. Та сама дисципліна процедури і строків працює на щоденній роботі, а не тільки на рідкісних подіях.
Що можна відновити після закриття
Найважливіше для керівника починається тоді, коли ситуація вже завершена.
Після серйозного інциденту зазвичай є відеозаписи, журнали кількох систем, дзвінки, повідомлення і пам’ять учасників. Чого зазвичай немає – це однієї послідовної історії реагування.
Тут працює правило, яке варто зрозуміти точно.
Умова переходу
За замовчуванням інцидент не можна перевести в стан «розв’язано», доки не завершені всі кроки процедури.
Обхід існує, але вимагає окремого повноваження – тобто є свідомим винятком, який теж лишається у записі.
Це і є механічний зв’язок між регламентом і результатом. «Процедуру виконано» перестає бути твердженням у звіті й стає умовою переходу.
Закритий інцидент більше не редагується, але вся інформація залишається в системі. Разом із записами про недотримання строків це дозволяє відновити не лише те, що сталося, а й те, як на це відреагувала організація: коли ситуацію взяли в роботу, які обов’язкові дії виконали, де процес затримався. Коли в реагуванні брали участь кілька команд, роботу кожної можна оцінити окремо.
Для керівника це закриває одну з найскладніших прогалин після інциденту: коли відомо, що сталося, але неможливо точно відновити, що саме робила організація у відповідь.
Три питання, які виникають раніше за налаштування
Все описане має одну особливість: воно не купується разом із ліцензією.
Система здатна вести процедуру, контролювати строки і фіксувати результат тільки після того, як організація сформулювала, що саме вона вважає правильною реакцією. Тому проєктування починається з трьох питань, і жодне з них не технічне.
- Які ситуації служба безпеки вважає інцидентом, а не просто подією.
- Де проходить межа між рішенням людини і дією системи – і які саме кроки організація готова віддати автоматиці.
- Що має лишатися відновлюваним і вимірюваним після того, як інцидент закрито.
Порядок проєктування
Спочатку описується операційний процес, потім модель інциденту, логіка реагування й допустимі межі автоматизації – і лише після цього система налаштовується під те, що вже описано.
Зворотний порядок дає працездатну конфігурацію і некерований процес.
