- PVSM.RU - https://www.pvsm.ru -
Есть две прекрасно работающие модели:
За последние несколько лет IT и телекоммуникации настолько слились, что различия в методологиях становится тормозом при реализации реальных технических проектов. Возможно ли совместить взгляды ИТ и технических специалистов в один? Мой ответ – да!
Попытки совместить эти два взгляда до сих пор сводятся к простому отображению одних понятий в другие, что не приближает к пониманию, а лишь подтверждает, что обе методологии по-разному описывают по сути одну и ту же деятельность. Возникает большое желание совместить эти два взгляда в один, уйдя от ярлыков «подход ИТ» и «подход телекоммуникаций» и фокусировавшись на сути. Суть же проста – предоставление сервисов.
Мы всё время находимся между двумя полюсами: определённостью и неопределённостью, развитием и операционной деятельностью. Пробегая PDCA, мы получаем опыт, расширяем свои знания и возможности. Но при этом цикл не даёт ответа на вопрос, где именно лежит граница между развитием и операционной деятельностью. Это важно, поскольку управление развитием и типовыми операциями сильно отличаются. Вторая проблема PDCA – это отсутствие фокуса на клиенте. Каждый раз мы смотрим в этом процессе на проблему изнутри компании: нам важны отлаженные процессы, эффективная инфраструктура, выполняемые показатели SLA. Но клиент при этом всё равно может оставаться недовольным.
Но прежде чем переходить ко второй модели, давайте посмотрим внимательнее на область Check. Она может быть разделена на две важных части:
В области планирования деятельности ситуация аналогичная. Мы можем планировать укладку стены после инцидента разрушения части стены (работа по устранению ошибок) или проект строительства великой стены (развитие системы)? Должен ли
укладчик кирпичей, которому выписан наряд на работы, задумываться об этом? И какой квалификацией и уровнем сознания должен обладать такой человек?
Таким образом, и область Plan может быть разделена на две подобласти:
Вот что у нас получается с циклом PDCA:
Обратите внимание на переходы от Check к Plan минуя этап Act, который оказывается не нужен, если речь идет о стандартных ошибках и стандартной реакции на неё.
Это даёт однозначные ответы на несколько частых вопросов:
— Можно ли не регистрировать инцидент?
Да, если ошибку обнаружила система мониторинга, ошибка незначительна, ее можно исправить автоматически или минимальными действиями (переход 1 на рисунке выше). Событие регистрируется на более низком уровне воронки событий – в журнале мониторинга, но до регистрации инцидента дело не доходит.
— Можно ли выполнять работы на инфраструктуре без согласования RfC?
Да, если это делает сама система мониторинга/управления инфраструктурой или если работа является типовой, стандартной (переходы 1 и 2 на рисунке). Необходимо лишь понимать влияние работы на прерывание сервиса и согласовать при необходимости временные окна этого прерывания. Изменение же всегда уникально, поэтому стандартных RfC не существует!
— Требуется ли классическое управление релизом для выполнения типовых работ или внедрения средств мониторинга?
Нет. Более эффективно работают упрощенные формы управления (переход 2 на рисунке).
Переход 1 показывает как работает автоуправение. При отклонении в системе логика автоматики или типовые инструкции людей позволяют быстро устранить проблему в короткий срок. Это похоже на опрос прерываний и действия по ним. Например, автоуправление – это автопилот самолёта. Или открытие клапана парового котла, если давление доходит до критической точки. При этом человек, открывающий клапан, может и не иметь квалификации достаточной для понимания своих действий. Стрелка в красной зоне – выполнил инструкцию.
Это переход 2. Если возникают ошибки, которые система не может откорректировать сама, вы подключаете более квалифицированных людей. Люди из центра мониторинга достаточно быстро устраняют проблему, используя свой стандартный сценарий. Например, если пилот самолёта видит, что автопилот отказал – он берёт ручное управление.
На переходе 3 идёт более медленный анализ, не имеющий типовых инструкций. Анализируются ошибки с невыясненной причиной, ситуация в целом и так далее. Основной показатель – качество анализа и качество варианта решения. Важно, что третий уровень не должен отнимать слишком много ресурсов – поэтому решение принимается в шаге Act в модели, то есть данные о состоянии системы передаются дальше. При этом при среднем влиянии на бизнес требуется компромисс между скоростью принятия решения и качеством анализа, а при сильном влиянии на бизнес – качество анализа, позволяющее принять оптимальное управленческое решение.
На области Act мы переходим из пассивного наблюдения за системой к активному её изменению. При этом мониторинг может выводить нас за Act для изменения системы с целью рутинной коррекции ошибки (операционная деятельность), либо для развития (существенного творческого – то есть нетипового изменения). При этом чем больше нетиповых опорных данных использовалось при переходе через Act – тем важнее будет решение, и тем точнее должна быть корреляция событий. Разделение между мониторингом и планированием позволяет представить BSS/OSS вот так:
Теперь посмотрим снова на PDCA
Есть две проблемы применения чисто этой модели:
Но у нас ведь уже есть BSS/OSS, расписанная по PDCA. Теперь мы просто объединяем эти две модели.
Процессов теперь ровно по два для каждого полюса. Почему? Здесь можно привести аналогию из области строительства. Мы привыкли рассуждать, что абсолютно весь бизнес управляется клиентским спросом. Тогда при строительстве дома логично было бы сперва найти на рынке первого клиента, согласного купить квартиру, заключить с ним сделку и построить ему угловую квартиру на первом этаже будущего дома. Так, клиент за клиентом, довести этажность дома до многоэтажки. Только ведь только никто так не делает. Строительство дома, и продажа квартир движутся параллельно, взаимозависимы и неотделимы друг от друга.
Прямой вывод, следующий из этой модели – важность соблюдения баланса между бизнесом и инфраструктурой, между проектами и мониторингом состояния. Вот та же модель от операций к развитию:
Workflow в такой модели – это два встречных потока событий, порождаемых клиентами и инфраструктурой. Модель клиентоориентирована, и ее содержание сильно зависит от вида клиента, с которым взаимодействует система. Такую модель лучше строить отдельно для клиента, поставщика, внутреннего сотрудника и т.д.
Вот пример:
Автор: AntonSavvin
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/45173
Ссылки в тексте:
[1] Источник: http://habrahabr.ru/post/196726/
Нажмите здесь для печати.