Манифест надёжности ИС
В теории надёжности High Reliability Organization (HRO) — организация, которая работает в условиях, где ошибка недопустима.
Термин появился в конце 1980-х годов. Исследователи (Карл Вайк, Кэтлин Сатклифф и другие) изучали, как в опасных средах удаётся поддерживать высокую надёжность. Изначально фокус был на авианосцах ВМС США, системах управления воздушным движением и атомных электростанциях — там, где технологии сложны, а цена ошибки огромна. Позже концепцию стали применять и в других сферах, в том числе в управлении критичными инф системами.
HRO-принципы:
1. Озабоченность сбоями (Preoccupation with failure). Организация не считает отсутствие инцидентов доказательством безопасности. Наоборот: каждый «почти сбой» (near miss) или слабое сигнальное отклонение воспринимают как признак уязвимости системы. ИС грохнулась из-за громоздкого документа, который пытались загрузить в систему? Почему? Это уязвимость, игнорировать нельзя. Выявился документ с изломанной ЭЦП? Ищем уязвимое звено, где ЭЦП сломали. Даже малейший сбой надо не закрывать на уровне симптома, а выявлять корневую причину и закрывать даже возможность его повторения. Все - уязвимость системы. Найди ее и обезвредь.
2. Отказ от упрощений (Reluctance to simplify). В HRO не спешат сводить сложную ситуацию к простому объяснению («это просто человеческий фактор»). Если есть несколько правдоподобных версий события, организация исследует их все. Сломали ЭЦП? Ерунда, всего один документ. Нет. Утечка данных? Ерунда, всего один раз. Нет.
3. Чувствительность к операциям (Sensitivity to operations). Организация постоянно держит руку на пульсе реальной работы. Это значит, что руководитель техподдержки не пишет отчёты, а сам видит все заявки и анализирует и предмет заявки, и то, что по ней сделано, и что не сделано, и делает то, что надо сделать. Он не сидит в кабинете. Он в каске, в поле, с лопатой. Он не только указывает — он и копает. Вместе с людьми.
4. Стремление к устойчивости (Commitment to resilience). Организация не просто планирует риски, а строит системы, которые могут поглощать сбои, адаптироваться и восстанавливаться в реальном времени. Зашиваем в код защиту от рисков. Зашиваем юр экспертизу в техподдержку ЭДО. Зашиваем идеологическое обучение пользователей в проекты внедрений. Зашиваем в ит-стратегию второй геораспределенный ЦОД. Зашиваем постоянный аудит административных действий. Все ИСы интегрируем в качестве реципиента к одному справочнику контрагентов, который ведётся одним подразделением с четкими правилами внесения изменений. Зашиваем проверку кадровиком перед созданием учётной записи.
5. Приоритет релевантной экспертизы (Deference to expertise). В ситуациях неопределённости или высокого темпа власть принимать решение смещается к тому, кто обладает наиболее релевантными знаниями и пониманием контекста, независимо от должности в иерархии. Если для достижения результата мне нужно принимать решения — я буду их принимать. Даже если выше меня по иерархии кто-то есть. Моя повседневная практика. Я решаю, и точка. Это помогла мне выполнить много проектов, которые без этого принципа никогда не были бы выполнены, или растянулись бы на годы.
👉На практике все эти принципы применяются одновременно и образуют среду, где: · ищут не виноватых, а причины — на стыках, в процессах, в условиях, в самых неочевидных местах; · есть психологическая безопасность. Люди не боятся ошибаться и говорить о просчете, потому что всегда знают: их выслушают без наказания. Данные об ошибке примут просто как факт, обдумаю причины и способы нивелирования и предупреждения, но не накажут; · формируется общее понимание процесса: все участники одинаково видят и интерпретируют риски. А для этого нужно говорить с участниками. Нужно делать так, чтобы они видели симптомы — красные флаги, могли их идентифицировать, и знали, что делать, если они увидели красный флаг.
· 21.10
Эх… Где то в параллельном мире наверное так оно и есть. А может быть и в этом , но пока просто не повезло встретить 😕
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 21.10
Надо просто соображать мозгом, когда управляешь системами. К сожалению, это да, редкое умение.
Поэтому и пишу. Пытаюсь родить осознание.
Я только в 2020 узнала про эти принципы. И увидела в них то, что я упорно строю. У меня наоборот все: сначала я на практике это использую и уже потом узнаю в какой нибудь новорожденной методологии.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 21.10
У меня в последнее время четкое ощущение дежавю - практически все проблемы которые происходят уже были - лет 30 назад на заре IT - на тестирования все летает, ой у нас тормозит наи пользователи жалуются, а почему запрос стоимостью плана выполнения миллиард такой медленный, а Хайп про "давайте внедрим ИИ для автоматизации" вообще дословно совпадает с энтузиазмом ERP, CRM, CAD/CAM. Просто выросло новое поколение которое ничему немусилось. И жто поколение сейчас принимает решения. Да что там говорить - фильм Премия - сейчас практически без изменений модно сделать ремейк - некоторые цитаты вообще менять не нужно, они в граните 😉
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён