Что же Ethernet-инженеру нужно знать о UML (Unified Modeling Language)? Да в целом ничего. ) Но это был бы слишком короткий пост...
Давненько я не графоманил, так что для начала немного философии. Если вы не хотите читать мои размышления, то вы можете пропустить N абзацов и перейти к заголовку "Что же такое UML?".
Философия
На самом деле, в наше время само понятие сетевого инженера несколько меняется. Я буквально на своей шкуре ощущаю эту метаморфозу. Связаны эти изменения с изменением самих сетей. Если раньше сеть представляла из себя набор сетевых элементов, и в лучшем случае, эти сетевые элементы были объединены некой NMS (EMS). То сейчас, с появлением NFV и SDN, ситуация меняется. Сеть уже начинает восприниматься несколько иначе. Как вы знаете, в SDN сетевые элементы сами по себе уже не определяют поведение всей сети, решение принимает некий контроллер. Речь идет про самое прямое понимание SDN. А в NFV, часть сетевых функций, ну скажем NAT, переносится на обычные виртуалки. Это два довольно больших аспекта, которые меняют представление о сетях. Два понятия часто идут вместе и описывают некий новый путь построения сетей. Иногда, даже когда нет в сети никаких контроллеров, но есть часть виртуализированных функций, все равно употребляют термин SDN/NFV.
Возможно, вы думаете, что все это происходит в лабораторных, институтах и прочих заведениях. Однако, SDN и NFV уверенно шагает по планетке. Если вы с ними не сталкиваетесь, это не значит, что они к вам не приближаются со спины.
Я столкнулся ещё с одной особенностью, которая была полнейшей неожиданностью для меня. У нас в стране, как мне кажется, есть стойкая тенденция управлять сетью руками. За бугром же, совершенно четко видно, что управлять железом непосредственно выглядит дикостью. В мире правят OSS системы, которые позволяют управлять сетью как единым целым. Конечно, это не является правилом. Это скорее мои наблюдения, которые основаны на некотором опыте.
К чему же я развел философию? К тому, что сетевой инженер нынче должен мыслить немного другими формами. Ну, как мне кажется, как минимум хороший сетевой инженер. Уверенные знания сетевых протоколов и вообще поведения сетей необходимы, но этого уже недостаточно. Современный сетевичек должен быть немного программистом и, если не уметь что-то написать, то хотя бы понимать, как вообще происходит весь процесс программирования. Не лишним будет представлять принципы объектно-ориентированного программирования, знать что такое базы данных и с чем их едят, понимать как работать с системами через API и все в этом духе.
Могу привести пример. Вы сетевой инженер в современной(!) компании. Ваша компания, как стремящаяся идти в ногу со временем, решает сократить капитальные расходы уведя часть сетевых функций в виртуальную среду (NFV). SDN в чистом виде вы не используете, пока что. В вашей конторе используются, к примеру, свеженькие Cisco ASR, мои любимые коммутаторы Extreme Networks и виртуальные файерволы от компании Palo Alto. Так же, часть функций вы подняли на виртуальных Juniper. И тут ваша компания решает соответствовать модным тенденциям и сократить расходы на персонал, что в целом разумно, если соблюдать баланс. Двух ваших коллег решено уволить, а вы с флагом в руках подписаны на оптимизацию процессов в вашей компании. Отныне, не ваши коллеги будут лопатить конфиги руками на сети, и даже не вы сами. Лопатить все будет некая система. Пусть это и набор питоновских скриптов, мы все равно назовем это системой. Вы, как не программист, не должны её писать. Однако вы должны объяснить людям как её писать, что она должна делать, и как она должна вести себя в той или иной ситуации. Поверьте, "чистому" сетевику очень сложно говорить с "чистым" программистом. Вы просто говорите на разных языках, вот и все. Говорить на одном языке вы не можете по причине того, что вы просто оперируете разными понятиями. Он вам твердит про объекты и атрибуты, а вы ему про железки и SFPшки. Что делать? Вопрос сложный. Идеальный вариант, вам нужно двигаться навстречу. Программисту узнавать как работают сети, а вам потихоньку разбираться в том, что же вам говорит программист. Конечно, ваш коллега-программист может и не захотеть двигаться вам навстречу. И это его проблемы. Вы то понимаете, что это неправильно. Поэтому вы должны узнавать больше. ) Накипело, видать, у меня. Тут мы подходим к теме поста. Помочь вам в общении сможет UML.
Что же такое UML?
Это унифицированный язык моделирования. Я не большой спец в нем, я только учусь, но название говорит само за себя. В теории, это способ объяснить что-либо другому человеку. UML покрывает довольно большое количество сценариев. В целом, когда вы в школе на информатике (я надеюсь) рисовали алгоритмы, это был почти UML. Сама нотация не привносит ничего нового, она лишь стандартизирует способы подачи информации в графическом виде. Сама идея состоит в том, что даже неподготовленный человек должен быть в состоянии понять то, что изображено в UML диаграмме. Она должна быть ясна и понятна для неподготовленного человека. Если же человек что-то понимает в UML, диаграмма должна предоставить ему лишь какие-то дополнительные сведения. Базовый смысл остается неизменным. Это в теории.
В UML великое множество типов диаграмм, но все они делятся на две больших категории.
- Structural (структурные) показывают структуру;
- Behavior (поведенческие) изображают поведение.
Близким к сетевику примером первой категории может быть диаграмма-изображение шасси, карт, слотов и прочей физической утвари современной железяки. Для второй категории подойдет в качестве примера диаграмма установления BGP-сессии или, скажем, в более сложном случае алгоритм-диаграмма настройки какого-либо сервиса. Все это мы и рассмотрим чуть ниже.
Следуя моему красочному примеру, в котором вы одни призваны автоматизировать работу отдела, нам надо описать/обрисовать следующие случаи для отдела разработки.
- Взаимоотношения между физическими сущностями в железке. Возьмем старичка Cisco 6509.
- Какие виды активностей вообще существуют в сети. Прокинуть влан, настроить порт, поднять пиринг с кем-нибудь.
- Как должно быть организовано взаимоотношение между системами. Как новая система должна обращаться к сети, какие ответы от неё ждать и прочее.
- Как система должны вести себя. Нужен реальный алгоритм, если порт в состоянии Down, перевести в Up, сбросить настройки, прокинуть VLAN, создать его и прочее.
Ясно, что все задачи выше хоть и приближены к жизни, но довольно рафинированные. Просто потому что я хочу описать в посте пример, а не начинать разработку полноценного ПО. )
Для наших целей подойдут следующие виды диаграмм:
- Component diagram. Диаграммы компонентов в русском варианте. Штука это довольно сложная, но мы как не программисты, упраздним половину ненужного и постараемся изобразить, как части железки относятся к друг другу.
- Use cases diagram. Диаграмма сценариев использования. Должна помочь нам изобразить, что вообще оператор творит с сетью, что нужно автоматизировать.
- Sequence diagram. Диаграмма последовательности. Тут мы опишем, как наша новая система будем взаимодействовать с сетью, что спрашивать и что ждать в ответ.
- Activity diagram. Диаграмма активностей. Это как раз как в школе, с ромбиками и прямоугольничками. Отражает детальную логику поведения системы.
Ещё раз замечу, что в UML великое множество видов диаграмм и все они так или иначе заточены под программирование и разработку ПО. С полным списком вы можете ознакомиться на просторах Интернета. Возможно, можно использовать другие типы диаграмм для наших примеров. Если вы их найдете, я буду только рад. На правду в последней инстанции не претендую, да и какая разница как все эти типы называются.
Component diagram
Начнем с простого. Давайте для возьмем Cisco Catalyst 6509. Мы знаем, что это шасси, в которое можно воткнуть какие-то модули. Модули бывают разные. Есть вентиляторы, есть блоки питания, есть процессоры, есть линейные карты. Более того, в линейные карты можно воткнуть SFPшки или иные трансиверы, а на процессорном модуле можно сменить память или, скажем, поставить другую фиче-карту (PFC). После того как вы расскажите это программисту, он расстроится и попросит вас это нарисовать. ) Чем и займемся.
Для
изображения объектов мы будем использовать просто прямоугольник, а для
того чтобы показать взаимотношение объектов будем использовать разные стрелки. В UML вообще миллион всяких стрелок, но мы
то мало что про него знаем, поэтому ограничимся несколькими. Описание смотрите под картинкой.
Руками рисовать будет долго, поэтому воспользуемся услугами draw.io.
Это неполное представление железной части 6509 в моем исполнении. Конечно, многое можно перерисовать, много можно дополнить. Схему можно делать как подробной, так и чисто ознакомительной. Я в какой-то момент понял, что начинаю уставать и ограничился детализацией "до порта". Бытро пробежимся сверху вниз.
- Сверху мы имеем объект - шасси 6509. Все, что расположено ниже, содержиться в этом шасси. Одно шасси имеет 2 слота под блоки питания. Для такого типа отношений есть специальная трелка с ромбиком. Вы можете видеть цифры у стрелок, они как раз и дают понимание о количественных показателях. Одно шасси содержит в себе 9 слотов и один слот для вентиляторов.
- Спускаемся на уровень ниже. Один или два блока питания используют один или два слота под них. Я написал 1 или 2, но можно было бы написать 0 или 2. В шасси, в общем-то, пожно и не втыкать вообще блоков питания, но я посчитал это слишком уж оторванным от жизни. Одна или две карты CPU используют один или два общих слота. Ноль или семь оставшихся слотов могут занять семь карт, а могут и не занять (0-7). И так далее...
- Ещё на уровень ниже. Тут можно увидеть, что CPU карта всегда имеет MSFS карту, PFC слот и один или много портов.
- И так далее...
Use cases diagram
Тут постараемся изобразить, что именно должна уметь наша система и какие пользователи будут иметь доступ к её функциям. Например, помимо автоматической настройки наших устройств, вы, как сетевой инженер, можете руками запустить какие-то процессы. А, например, специалист поддержки может посмотреть статус какого-то действия.
Диаграмма получилась, скажем прямо, так себе. Однако общий смысл все равно, я надеюсь, понятен. Мы, как Администратор, изображенный слева, можем запустить создание VLANа, его удаление и добавление на интерфейсы. Все эти процессы проходят в нашей системе The System. Эти три операции дополняет операция сохранения конфигурации, которую дополняет операция просмотра статуса. После добавления VLANа на интерфейс нужно проверить доступ до железки (если вы вдруг забыли добавить "add" в "switchport allowed vlan"). Эта операция дополняет операцию добавления VLANа на интерфейс. Инженеру поддержки мы как-то не очень доверяем, судя по всему. Именно по этому. он может только смотреть статус.
Sequence diagram
Возьмем самый простой случай прокидывания VLANа на железке. У нас есть:
- оператор - смотрит за выполнением процесса,
- наша "система", которая выполняет какие-то операции,
- железка в сети, над которой происходят какие-то манипуляции.
Activity diagram
Возьмем пример из прошлой диаграммы. Однако теперь нам надо описать логику поведения, а не то как части процесса общаются друг с другом. Тут все должно быть знакомо, если не влезать в тонкости. Активности в овалах, условия в ромбиках.
В рамках системы начинается процесс, сразу же система должна спросить параметры у пользователя (допустим, адрес и SNMP community). Если параметры не были получены, то вылетает ошибка и процесс прекращается. В положительном пути отправляется запрос на устройство. Если нет ответа, система снова вываливается с ошибкой. А вот если ответ получен, система обновляет статус операции и красиво завершается.
Вот как-то так можно использовать UML в будничной жизни современного сетевого инженера. Прошу прощения у программистов, которые прочитали этот пост. Возможно, я местами мог вас обидеть. Этого я делать никак не хотел. Давайте жить дружно. )
Комментариев нет:
Отправить комментарий