В прошлой статье я лишь поверхностно коснулся ситуационной модели, и может показатся, что это не модель, а «срочная неразбериха». На самом деле это далеко не так. Ситуационная модель — на 90% состоит из заготовленных сценариев, остается только их правильно компоновать.
Ситуации бывают разные. Это всем нам известно, в прошлый раз я приводил как пример отделение полиции, а в этот раз приведу пример караульной службы.
Что такое караульная служба?
— Ефрейтор Карасев, пост сдал!
— Рядовой Кичман, пост принял!
Все просто, скучно и однообразно. Но все ради одного. Ради события. Вот рядовой Кичман увидел в темноте как на противоположной горе светят огоньки в лесу. Согласно инструкции он будит своего «второго», показывает ему, они считают количество костров в лесу на склоне. Это они оценивают обстановку. Кичман посылает второго в палатку разбудить офицера — ситуация то серьезная, они насчитали 43 костра, а если даже по четыре человека у одного — это 172 «чеха».
Офицер принимает единственное верное и соответствующее инструкциям и всему, чему его учили решение — сообщить в штаб и просить подкрепление. Штаб находится от позиции всего в двух часах перехода, а БТР проходит его за 15 минут.
Когда позиция укреплена прибывшими и разместившимися бойцами, о чем офицер своевременно докладывает, в воздухе слышится противный шум и лес на противположном склоне вспыхивает яркими огнями взрывов и шумом падающих деревьев — это работают Град по приказу штаба. Подавить до нападения — тоже самое верное решение.
Утром к позиции прибывает рота разведки и отправляется на склон осмотреть место, посчитать трупы и добить оставшихся, может кого и допросить выйдет. Если повезет.
Так как же выглядело решение этой ситуации буквами учебника?
Мы с Вами не отвечаем за жизни и границу между Чечней и Грузией. Мы решаем бизнес-ситуации. Ситуации упавших серверов, внезапных фич и неожиданных лендингов.
Это требует тех же инструкций, того же плана. Мы должны мониторить сервера и регулярно интересоватся планами у бизнеса, чтобы сразу обнаружить «ситуацию».
Мы должны правильно ее классифицировать и оценить. Лендинг для мобильной аудитории? Легко! 8 часов верстки, 2 — тестирования, 1 — на использование API регистрации.
Сдох HDD в RAID? А тут понятно, нужно заменить сдохший.
Пришел баг с живой системы? Да, тут нужен бакендер-подкрепление. Есть кто свободный? «На, держи баг!»
Мы должны понимать осложнения от ситуации. Не заменим HDD — в следующий раз потеряем данные. Неверно оценим время на лендинг — бизнес потеряет это время, не мы. Баг поправит Junior? Значит жди еще три бага к вечеру и еще один к утру.
Мы должны решать ситуации до их осложнения — HDD запасной у меня всегда в ДЦ в стойке на полу лежит. Нужно заменить — я звоню знакомому сапорту датацента и он меняет. Конечно корзины в серверах пронумерованы и на сломаном моргает индикатор — даже дурак не перепутает. Для лендингов всегда есть заготовки, обкатанное и документированние API для регистраций — это не дает превратится верстке лендинга в разработку частей системы.
Ко сожалению у меня очень мало чужих примеров успешного ситуационного управления, а сам хвастаится не хочу. Если он есть у Вас — welcome в комментарии, я буду очень рад услышать Ваши примеры успеха в этом деле.
Еще стандартные ситуации легко автоматически находить, и так же автоматически чинить. Это и резервирование, и добавление места в логический volume LVM автоматом, это и Hot Spare диски в Raid.
Если Вы разработаете список стандартных ситуаций и их решений — Ваша жизнь и жизнь проекта станут гораздо легче, проще и спокойнее. Ведь всегда проще «адовый срочняк» решать по проверенному плану, чем импровизируя на дрели, тем более что иногда и гранит попадается плохо сверлящийся.
Ситуации бывают разные. Это всем нам известно, в прошлый раз я приводил как пример отделение полиции, а в этот раз приведу пример караульной службы.
Что такое караульная служба?
— Ефрейтор Карасев, пост сдал!
— Рядовой Кичман, пост принял!
Все просто, скучно и однообразно. Но все ради одного. Ради события. Вот рядовой Кичман увидел в темноте как на противоположной горе светят огоньки в лесу. Согласно инструкции он будит своего «второго», показывает ему, они считают количество костров в лесу на склоне. Это они оценивают обстановку. Кичман посылает второго в палатку разбудить офицера — ситуация то серьезная, они насчитали 43 костра, а если даже по четыре человека у одного — это 172 «чеха».
Офицер принимает единственное верное и соответствующее инструкциям и всему, чему его учили решение — сообщить в штаб и просить подкрепление. Штаб находится от позиции всего в двух часах перехода, а БТР проходит его за 15 минут.
Когда позиция укреплена прибывшими и разместившимися бойцами, о чем офицер своевременно докладывает, в воздухе слышится противный шум и лес на противположном склоне вспыхивает яркими огнями взрывов и шумом падающих деревьев — это работают Град по приказу штаба. Подавить до нападения — тоже самое верное решение.
Утром к позиции прибывает рота разведки и отправляется на склон осмотреть место, посчитать трупы и добить оставшихся, может кого и допросить выйдет. Если повезет.
Так как же выглядело решение этой ситуации буквами учебника?
- Вовремя заметить изменение обстановки (обнаружить ситуацию)
- Оценить обстановку, сложность и опасность сложившейся ситуации.
- Принять все меры, чтобы ситуация не приняла развития и ухудшения обстановки (вызвать подкрепление)
- Решить ситуацию максимально простым путем (не вступая в бой, применить Град)
- Убедиться в том что ситуация не повторится (выслать разведку)
Мы с Вами не отвечаем за жизни и границу между Чечней и Грузией. Мы решаем бизнес-ситуации. Ситуации упавших серверов, внезапных фич и неожиданных лендингов.
Это требует тех же инструкций, того же плана. Мы должны мониторить сервера и регулярно интересоватся планами у бизнеса, чтобы сразу обнаружить «ситуацию».
Мы должны правильно ее классифицировать и оценить. Лендинг для мобильной аудитории? Легко! 8 часов верстки, 2 — тестирования, 1 — на использование API регистрации.
Сдох HDD в RAID? А тут понятно, нужно заменить сдохший.
Пришел баг с живой системы? Да, тут нужен бакендер-подкрепление. Есть кто свободный? «На, держи баг!»
Мы должны понимать осложнения от ситуации. Не заменим HDD — в следующий раз потеряем данные. Неверно оценим время на лендинг — бизнес потеряет это время, не мы. Баг поправит Junior? Значит жди еще три бага к вечеру и еще один к утру.
Мы должны решать ситуации до их осложнения — HDD запасной у меня всегда в ДЦ в стойке на полу лежит. Нужно заменить — я звоню знакомому сапорту датацента и он меняет. Конечно корзины в серверах пронумерованы и на сломаном моргает индикатор — даже дурак не перепутает. Для лендингов всегда есть заготовки, обкатанное и документированние API для регистраций — это не дает превратится верстке лендинга в разработку частей системы.
Ко сожалению у меня очень мало чужих примеров успешного ситуационного управления, а сам хвастаится не хочу. Если он есть у Вас — welcome в комментарии, я буду очень рад услышать Ваши примеры успеха в этом деле.
Еще стандартные ситуации легко автоматически находить, и так же автоматически чинить. Это и резервирование, и добавление места в логический volume LVM автоматом, это и Hot Spare диски в Raid.
Если Вы разработаете список стандартных ситуаций и их решений — Ваша жизнь и жизнь проекта станут гораздо легче, проще и спокойнее. Ведь всегда проще «адовый срочняк» решать по проверенному плану, чем импровизируя на дрели, тем более что иногда и гранит попадается плохо сверлящийся.
S_A
Откройте для себя ITIL (или даже CobiT). И средства мониторинга. Работал я в своё время с отделами мониторинга разных крупных заказчиков (опсосы и банки в основном).
Стандартно: вся ИТ-инфраструктура побита по ИТ-сервисам (точнее там всё посложнее слегка, но в данном контексте не суть), для которых предусмотрены все типовые реакции на случаи отклонений от нормы в функционировании, системы мониторинга собирают метрики, при нарушении определенных диапазонов (у HP есть хороший термин health model), автоматически заводятся инциденты, которые классифицируются (иногда автоматически), различными способами уведомления летят от инженеров до президентов (кто на что захотел, тот на то и подписался). На основе одного или ряда инцидентов анализируются корневые причины и прочее и прочее… весь ITIL не перескажу (кстати с того момента, когда я по нему сертифицировался, он сильно видоизменился). Скажу, что там и периодические регламентные работы определяются и управляются. И даже процессы внедрения нового функционала (уже готового).
Теперь о плановом и ситуационном управлении. У этих «управлений» — разные цели, несмотря на то что, непосредственно объекты управления могут быть одними и теми же (сайт например, или сотовая связь). У планового управления цель — изменение объекта управления, у ситуационного — устранение отклонений от определенной нормы в ходе эксплуатации конкретного экземпляра объекта управления.
piromanlynx
Вы так пишите, как будто у нас ничего нет, ни мониторинга, ничего. Ну зачем Вы так? Вокруг умные здоровые умом люди.
piromanlynx
Я как то решил не писать такой банальный момент, вроде как и так понятно
S_A
Я не в курсе того, что у Вас есть, в том числе и что для Вас банальность. Просто Вы не ссылаетесь на зарекомендовавшие себя практики. Что касается банальности момента, то это тот камень, от которого все действия по управлению (одним и тем же объектом до некоторой степени) в разные стороны разъезжаются.
Если есть желание объединить PM и ITSM в единую концепцию, то опять же с этого камня начинать надо. На данный момент в отрасли это концептуально сводится…
1. деньгами :) Инвестиции, операции и чистый доход,
2. техническими практиками (по типу continuous integration и тому подобных в кучке),
3. с точки зрения управления — программным менеджментом.
piromanlynx
Простите… Вы помоему меня не поняли. Я ссылаюсь на общепринятую практику появившуюся за 1000 лет до появления IT, зарекомендовавшую себя за эту 1040 лет. Я провожу параллель между практиками военного и оханного дела и современным IT (который по какой то случайности эти практики пытается придумать заново). Вы говорите модными сокращениями в 2-4 буквы вроде «PM» и «ITSM», а я говорю понятным всем языком — вот разница между нашими взглядами.
Странный у нас диалог… Вы ничего обо мне не знаете, при этом учите. Правда странно. Хотя может быть и я Вас не понял.
S_A
Ваши параллели — либо доморощенная наколенщина, либо попытка создать теорию всего в менеджменте. В первом случае пост похоже ориентирован на аудиторию из любопытных домохозяек, во втором случае теория не изложена.
И да. Что-то я все-таки знаю. Вы пишете на Мегамозге посты в хабе «Управление проектами».
piromanlynx
Ой, а Вы не в курсе? Она же давно уже есть! Конфуций, Макиавелли, Форд и много других умных людей уже давно изложили массу умных мыслей о менеджменте (только они это называли другим словом). Создавать теорию всего совсем не надо — она есть и давно и налаженно работает в руководящих аппаратах государств.
S_A
Про Конфуция, Макиавелли и Форда я очень давно как в курсе. Я про конкретный пост на конкретном ресурсе писал (где попадаются читатели, которые в курсе многого относительно управления ИТ-проектом и ИТ-инфраструктурой).
Я б уже забил. Отсылки к военному делу хороши (я бы даже сказал приятны), и практик там интересных куча (сам офицер запаса:)), просто вот скажем, проектное дело в производстве — хоть и достаточно молодая (по сравнению с военным искусством) дисциплина, тем не менее обросла своими подходами и практиками.
Даже больше. Например в СССР была феноменальная плановая система управления. Она совмещала эксплуатацию существующих объектов, модернизацию, ввод новых. Объединялось все это конечными целевыми показателями. Неэффективность системы скрывалась причем не в методе :) Посмотрите здесь например. Не суть.
Возвращаясь к нашей ситуации, переформулирую мысль: можно искать паралелли, но зачем, если есть непосредственные методы (конечно паралелли есть, и даже между ITSM и управлением боевыми соединениями). Просто за сравнением конкретных ситуаций и управления в них, общего подхода все же не усматривается, а обоснование отсылками «на войне делают так» представляет интерес как любопытное сравнение, но не как инструмент.
А инструмент бы не помешал, потому что как я уже говорил, существует отдельно ITSM, отдельно PM, а практики их совмещения как стандарта нет (если не брать в расчет килограмм 20 стандартов ИСО).