Не ищите виноватых в ИТ. Привилегия на ошибку

Вне зависимости от масштаба вашей организации и используемого оборудования, периодически возникают различные неполадки. То доступ к сети прерывается, то одна из систем дает сбой, то случается что-то еще. Естественно, при обнаружении проблемы, ответственные сотрудники принимают все возможные меры для скорейшего восстановления работоспособности.

После восстановления проводится анализ причин произошедшего инцидента и разрабатываются меры для предотвращения подобных ситуаций в будущем. Все это можно охарактеризовать как «Процесс управления инцидентами».

Как правило, в компаниях применяется один из подходов к реагированию на инциденты:

Стартап или небольшая фирма.

В случае любых проблем и аварий, все сотрудники обращаются к конкретному специалисту. Он, в свою очередь, анализирует обстановку и решает возникшие вопросы.

Средний бизнес

Более крупная компания, где поддержка ИТ-инфраструктуры осуществляется несколькими сотрудниками или даже отделами. В подобных ситуациях часто создаются общие чаты в мессенджерах, где все возникшие инциденты обсуждаются коллегиально. Сотрудник, обнаруживший проблему в своей зоне ответственности, предоставляет коллегам подробную информацию об инциденте и делится субъективной оценкой времени, необходимого для восстановления.

Крупный бизнес

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

И хотя все это звучит современно и технологично, нюансы кроются в деталях…

Давайте более подробно рассмотрим последний вариант с процессом и комиссией, которая занимается анализом инцидентов, учитывая, что все участники процесса — люди.

Комиссия по авариям

В ее состав входят уважаемые сотрудники, занимающие соответствующие должности. Они по праву занимают эти посты и обладают широким кругозором, знаниями и опытом. Однако, очевидно, что они не могут знать все. И не всегда им может хватить компетенции для вынесения корректного суждения. Например, они обладают значительным опытом в области системного администрирования серверов, но проблема возникла в сетевой среде, в протоколах динамической маршрутизации, о которых они только читали или слышали.

С другой стороны, их роль подразумевает принятие решения, даже при недостаточном уровне знаний в конкретной области.

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

Со временем вырабатывается стандартный алгоритм поведения членов комиссии по разбору инцидентов. Анализ любого инцидента должен дать им ответы на два вопроса: кто виноват и что делать?

Инженеры

Теперь посмотрим на этот процесс глазами ответственного сотрудника. Во время инцидента он оперативно отреагировал на проблему, устранил ее последствия и восстановил работу своей системы.

Он молодец?

Да, безусловно. Но практически сразу после инцидента к нему обращается коллега или руководитель с просьбой подготовить отчет, в котором подробно описывается случившееся. Естественно, с указанием точного времени, всех деталей и в соответствии с установленной формой.

Даже если все причины известны и понятны, оформление их на бумаге требует времени и усилий. А если окажется, что сбой произошел после действия самого сотрудника? А он тоже человек. И он не хочет чувствовать себя виноватым. Поэтому вместо решения текущих задач он начинает думать, как представить факты так, чтобы избежать ответственности.

Чем крупнее организация, тем более формализован данный процесс и тем сильнее может сложиться впечатление, что все эти отчеты и разборы являются частью системы наказания сотрудника за факт возникновения инцидента.

Кто больше всего страдает от подобного подхода?

Примем за данность, что люди совершают ошибки.

ИТ-специалисты, отвечающие за поддержание инфраструктуры в рабочем состоянии, не исключение. Предположим, что специалист ошибается в одном случае из тысячи операций. И простая опечатка в процессе настройки какого-либо оборудования может и вовсе не повлиять на работу системы. Например, если инженер ошибся в поле description. И с такой же вероятностью опечатка в конфигурации может привести к потере доступности важного для компании ресурса или даже всей инфраструктуры.

В любом случае, чем больше специалист выполняет операций, тем больше ошибок он совершает. Другими словами, тот, кто больше работает, больше и ошибается, и, следовательно, больше страдает от подобного отношения к инцидентам.

Получается, что процесс, созданный для борьбы с инцидентами, в некоторых случаях начинает давать обратный эффект:

• во-первых, тратит больше времени сотрудников, отвлекая их от решения повседневных задач и увеличивая риск возникновения инцидентов.
• во-вторых, косвенно наказывает тех, кто работает больше всех.

Не правда ли, это не совсем правильно?

Критикуешь? Предлагай!

В первую очередь, при любом из подходов к управлению инцидентами, я советую не искать виновных. Все без исключения участники процесса: пользователи, специалисты, руководители и даже владельцы компании, вместо поиска виновных, должны быть сосредоточены на быстром выявлении причин возникновения инцидентов и их последующем устранении. Это возможно только в том случае, если все будут уверены в том, что за правду им ничего не будет.

Другими словами, при любом инциденте необходимо задавать вопрос: «Что и кто делал последним?» И на него каждый специалист должен честно и без промедления отвечать: «Ничего не делал» или «Сделал то-то и там-то». Если инцидент вызван человеческим фактором, это позволит в разы сократить время на его устранение. Если взглянуть на ситуацию глубже, можно сказать, что у специалиста есть право, вернее Привилегия на ошибку.

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

Опытный специалист не боится совершать ошибки. Через них он получает ценный опыт и понимание сильных и слабых сторон системы в целом.

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

Девизом специалиста должна стать фраза: «Сломал? Почини!»

Помните об ответственности

Каждый специалист должен знать, что за единичный инцидент, вызванный именно его действиями, не последует никакого наказания. Однако все будут ожидать от него активного участия в разборе причин.

В случае повторного инцидента следует рассмотреть вопрос об изменении ИТ-процесса в компании, который, возможно, приводит к ошибкам, связанным с человеческим фактором.

И только при третьем повторении одного и того же инцидента с участием одного и того же специалиста стоит рассматривать вопрос о каких-либо мерах.

Подводя итог всему вышесказанному:

• Не ищите виновных, это в конечном итоге приведет к увеличению числа инцидентов или времени на их устранение. А, следовательно, к прямым убыткам компании.
• Вместо этого старайтесь максимально сократить время на поиск причин инцидентов.
• Если система не работает, никто ничего не делал и непонятно, что с ней делать, просто перезагрузите ее.