В прошлой статье я лишь поверхностно коснулся ситуационной модели, и может показатся, что это не модель, а «срочная неразбериха». На самом деле это далеко не так. Ситуационная модель — на 90% состоит из заготовленных сценариев, остается только их правильно компоновать.
Ситуации бывают разные. Это всем нам известно, в прошлый раз я приводил как пример отделение полиции, а в этот раз приведу пример караульной службы.
Что такое караульная служба?
— Ефрейтор Карасев, пост сдал!
— Рядовой Кичман, пост принял!
Все просто, скучно и однообразно. Но все ради одного. Ради события. Вот рядовой Кичман увидел в темноте как на противоположной горе светят огоньки в лесу. Согласно инструкции он будит своего «второго», показывает ему, они считают количество костров в лесу на склоне. Это они оценивают обстановку. Кичман посылает второго в палатку разбудить офицера — ситуация то серьезная, они насчитали 43 костра, а если даже по четыре человека у одного — это 172 «чеха».
Офицер принимает единственное верное и соответствующее инструкциям и всему, чему его учили решение — сообщить в штаб и просить подкрепление. Штаб находится от позиции всего в двух часах перехода, а БТР проходит его за 15 минут.
Когда позиция укреплена прибывшими и разместившимися бойцами, о чем офицер своевременно докладывает, в воздухе слышится противный шум и лес на противположном склоне вспыхивает яркими огнями взрывов и шумом падающих деревьев — это работают Град по приказу штаба. Подавить до нападения — тоже самое верное решение.
Утром к позиции прибывает рота разведки и отправляется на склон осмотреть место, посчитать трупы и добить оставшихся, может кого и допросить выйдет. Если повезет.
Так как же выглядело решение этой ситуации буквами учебника?
- Вовремя заметить изменение обстановки (обнаружить ситуацию)
- Оценить обстановку, сложность и опасность сложившейся ситуации.
- Принять все меры, чтобы ситуация не приняла развития и ухудшения обстановки (вызвать подкрепление)
- Решить ситуацию максимально простым путем (не вступая в бой, применить Град)
- Убедиться в том что ситуация не повторится (выслать разведку)
Мы с Вами не отвечаем за жизни и границу между Чечней и Грузией. Мы решаем бизнес-ситуации. Ситуации упавших серверов, внезапных фич и неожиданных лендингов.
Это требует тех же инструкций, того же плана. Мы должны мониторить сервера и регулярно интересоватся планами у бизнеса, чтобы сразу обнаружить «ситуацию».
Мы должны правильно ее классифицировать и оценить. Лендинг для мобильной аудитории? Легко! 8 часов верстки, 2 — тестирования, 1 — на использование API регистрации.
Сдох HDD в RAID? А тут понятно, нужно заменить сдохший.
Пришел баг с живой системы? Да, тут нужен бакендер-подкрепление. Есть кто свободный? «На, держи баг!»
Мы должны понимать осложнения от ситуации. Не заменим HDD — в следующий раз потеряем данные. Неверно оценим время на лендинг — бизнес потеряет это время, не мы. Баг поправит Junior? Значит жди еще три бага к вечеру и еще один к утру.
Мы должны решать ситуации до их осложнения — HDD запасной у меня всегда в ДЦ в стойке на полу лежит. Нужно заменить — я звоню знакомому сапорту датацента и он меняет. Конечно корзины в серверах пронумерованы и на сломаном моргает индикатор — даже дурак не перепутает. Для лендингов всегда есть заготовки, обкатанное и документированние API для регистраций — это не дает превратится верстке лендинга в разработку частей системы.
Ко сожалению у меня очень мало чужих примеров успешного ситуационного управления, а сам хвастаится не хочу. Если он есть у Вас — welcome в комментарии, я буду очень рад услышать Ваши примеры успеха в этом деле.
Еще стандартные ситуации легко автоматически находить, и так же автоматически чинить. Это и резервирование, и добавление места в логический volume LVM автоматом, это и Hot Spare диски в Raid.
Если Вы разработаете список стандартных ситуаций и их решений — Ваша жизнь и жизнь проекта станут гораздо легче, проще и спокойнее. Ведь всегда проще «адовый срочняк» решать по проверенному плану, чем импровизируя на дрели, тем более что иногда и гранит попадается плохо сверлящийся.
Автор: piromanlynx
