Методология PPDIOO

Следующий модуль нашего курса про коммутацию будет посвящен очень важной и совершенно незаслуженно игнорируемой теме. Это методология работы с IT-средами. Дело в том, что, наверное, для всех это будет актуально. У всех так или иначе метод развития в сетевых технологиях был плюс-минус километр один и тот же, что мы начинали работать с самообразованием методом научного тыка. Мы смотрели, как работают те или иные штуки, мы интересовались тем, как работают коммутаторы, маршрутизаторы. Начинали их как-то настраивать по наитию, потом приходили к тому, что либо то, что мы настроили, работает не очень хорошо, либо, соответственно, понимали, что то, что мы настроили, как-то работает и ладно, но хотелось чего-то большего. И дальше начинали учиться тому, как делать какие-то вещи правильно.

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

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

В принципе, есть другие фреймворки. Например, есть общий IT-шный фреймворк, который называется ETL. Он про то, как вообще работать в IT-индустрии. Есть фреймворк про микрософтовские всякие продукты, называется MOV, Microsoft Operational Framework. Ну и вот у Cisco есть методология, есть фреймворк, который называется PPDIOO. Plan, Prepare, Design, Implement, Operate, Optimize. Суть очень простая. Если у вас возникает что-то, что вы хотите сделать, вы должны это разбить на определенные шаги и на каждом шаге выполнять определенные действия. Если вдруг где-то что-то пойдет не по плану, то, соответственно, у вас будет понимание, почему это пошло не по плану и что сделать для того, чтобы вернуть проект обратно в русло плана. Вы, наверное, замечаете, что слайд, который я вам предлагаю, он немножко необычный, потому что на нем нет кучи разных слов. Есть вместо этого картинки.

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

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

То есть вам не дают еще в руки деньги, но говорят, что если вдруг ты хочешь что-то сделать, давай посчитай, сколько это стоит, и мы тебе в принципе морально готовы определенную сумму выдать для того, чтобы ты решил определенную проблему. То есть вы поняли, да? То есть это еще не сами деньги вам в руки псуют, но вам дают своего рода кредитную линию для того, чтобы вы с ней могли работать. Дальше вы должны будете составить план. Следующий шаг, план, будет означать, что вы прорабатываете так называемый топ-левел дизайн. Решение, вы понимаете, что вы будете делать, из каких шагов оно будет состоять. Примерно прикидываете бюджет. В тот момент, когда вам сказали на этапе prepare, ну ты посчитай, сколько это все стоит, вы говорите, окей, начинаем считать. Прикидываем плюс-минус километр бюджеты. Прикидываем плюс-минус километр основные компоненты решения. Прикидываем плюс-минус километр, сколько нам потребуется людей для внедрения проекта, сколько нам потребуется ресурсов, сколько, ну то есть что мы делаем вообще, да?

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

То есть это предполагает, что вы составляете бюджет. И дальше от этого бюджета вы уже плюс-минус километр отклоняться особо не можете. Но тем не менее на этапе вот этого самого планирования вы понимаете, сколько там ну хотя бы нулей в общей сумме будет. Если вам нужно развернуть, не знаю, новый филиал, то вы должны будете понять, это будет там 100 долларов, 1000 долларов, 10 тысяч долларов, 100 тысяч долларов. Понятно, что если вы скажете, что это будет 1000 долларов, а по факту это будет полторы, на вас будут косо смотреть. Но тем не менее как бы такого масштаба рост стоимости, он в принципе допустим. Это не будет считаться, что это вы как-то очень сильно накосячили. Но если вы сказали, что это будет стоить 1000 долларов, а по факту это будет стоить 100 тысяч, ну тут понятное дело, вас просто не согласятся вам столько денег выдать, и ваш проект будет провален. Ну то есть очевидно, да, что в этом случае получается, что это была ошибка. Ошибка на этапе планирования. Сколько денег вы просили, сколько денег это по факту заняло. Вот.

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

а как-то иначе. Что делать в этом случае? Типичный пример, да, что вот мы, допустим, собираемся добавить новый дистрибьюшн-блок в сеть. У нас построилось новое здание на территории, мы хотим подключить это здание к сети. Вот мы должны будем сделать, мы должны будем, значит, включить все свечи в дистрибьюшн в этом здании, от дистрибьюшнов проложить провода в ядро и дальше в ядре прописать все соответствующие настройки. На свечах ядра мы там говорим, что у нас есть вот несколько новых портов, которые смотрят в сторону нового дистрибьюшн-блока, бла-бла-бла. Пример, с которым вот недавно пришлось столкнуться. Не мне, к счастью, но я был, так сказать, свидетелем. Два свеча в ядре, Nexus и S-Bitonica. Включаются в них новые пользователи. Один из свечей гаснет целиком, вся коробка. Коробка стоит там хорошо за миллион. Ну, соответственно, включается,

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

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

мы по факту сделали другое. Если, допустим, вы где-то планируете поставить свитчи, вы говорите, окей, на этапе дизайна у нас запланирован свитч, там, 48-портовый. Пришли на склад, пытаемся взять 48-портовый свитч, а выясняется, что вместо него привезли 24-портовый. Но, в принципе, его тоже хватит. Мы не просто говорим, окей, берем, что дают, мы фиксируем все, что не соответствует дизайну, мы говорим, окей, на складе не было того, что было запланировано, но был тот свитч, который, как нам кажется, решит проблему тоже. Поэтому там, где в дизайне написано 48-портовый свитч, мы это зачеркиваем, пишем 24-портовый. В итоге на этапе имплемент у нас получается реализованная структура, которая прописана в дизайне, плюс набор изменений относительно дизайна. Дальше начинается этап нормальных операций. То есть мы сказали, мы сделали то, что мы собирались сделать,

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

Это этап Optimize. Вы вносите предложение на то, чтобы переделать какой-то кусок вашей сети, и, соответственно, переходите в следующий проект. Фазу Prepare следующего проекта, который точно так же пройдет весь полный круг, и так или иначе у вас все взаимодействие будет идти вот в этом цикле. Готовимся к какому-то проекту, планируем этот проект, дизайним, внедряем, обслуживаем, оптимизируем, переходим к следующему проекту и так далее. На экзамене весьма вероятно у вас будут вопросы, вида, вы подошли к генеральному директору и хотите у него попросить денег на то, чтобы он вам дал на новый свитч. Типа, что это такое? Это Prepare, это план, это дизайн и так далее. Ну вот, соответственно, да, по книжке вы можете посмотреть разбиение фаз, какие действия будут соответствовать какой фазе. Но если вкратце, вот шпаргалочка будет такая,

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

которая называется вот... Назовем это рабочая документация. Даже не та, которая проектная документация. Вы начинаете просто понимать, в какую сторону вы копаете, что вы делаете. То есть, ну, вообще это дизайн, разработка дизайна, по большому счету. На этапе дизайн вы разрабатываете низкоуровневый дизайн, то есть все вот мелочи, которые есть. Собираете спеки от подрядчиков, собираете... Начинаете писать документацию, кто, куда, чего, зачем и почему. Имплемент. Ну, тут все понятно, да, что это... Внедряете, обновляете документацию, тестируете, что все пошло по плану. Operate. Просто обычная нормальная работа. То есть, учет... Типичный пример, да, что вот если вы там решили Active Directory развернуть, вы его развернули, и дальше надо в эту Active Directory учетки заводить. Если вдруг что-то там зависло, там контрольный домен надо перезагрузить. Ну, перезагружаете. Это вот просто нормально и повседневная работа, и плюс мониторинг того, что вы сделали. Может быть, какие-то

незначительные модификации вашего решения, вашего проекта, опять же, с обязательным отражением в документации. Может быть, какие-то твики производительности. То есть, если вы видите, что сервер как-то чуть-чуть подтормаживает, но можно, допустим, вместо харда поставить SSD-шник, ну, и вы знаете, что это ни на что не повлияет, что в проекте нигде не записано, что это должен быть обязательно хард. Ну, можно взять, быстренько подмахнуть SSD-шник на хард. Это, в принципе, небольшой проект. То есть, нет смысла ради этого заводить отдельный там бюджет, отдельно что-то. Но это можно просто в рамках operations сделать. Ну, и, наконец, последнее, это optimize, вы понимаете, что решение строилось под какие-то потребности. И эти потребности, они постоянно меняются. Если вдруг выясняется, что решение, которое вы предложили, оно уже не отвечает актуальным бизнес-потребностям, значит, надо строить новое решение. И вы, понимая, что это нужно, формируете новый дизайн, оцениваете новые заново потребности,

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

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