Pull to refresh

Автоматизируй, когда можешь, программируй, когда необходимо

Reading time 5 min
Views 11K
Original author: Jason Edelman
Здравствуйте, уважаемые читатели

Вот-вот в издательстве O'Reilly выйдет очередная занятная книжка с крокодилом


Этот увесистый компендиум всесторонне освещает вопросы о том, в какой степени сисадмин должен быть «network engineer», как оптимально соотносится автоматизация и программирование в работе такого специалиста. В книге даются основы Linux и Python, а также ожидается еще масса всего интересного.

Чтобы вам было интереснее участвовать в голосовании, предлагаем почитать небольшую статью одного из авторов (Джейсона Эдельмана), в которой он рассказывает, какие мысли подтолкнули его к сотрудничеству с Мэттом Освальтом и созданию этой книги

Мысли, которыми я поделюсь с вами в этой статье, довольно долго не давали мне покоя. Я давно уже хотел об этом написать, но, стоило мне бегло прочесть статью Мэтта Освальта Learn Programming or Perish(?) – и картинка в голове сложилась, оставалось только опубликовать собственную статью. Здесь я хотел развернуто рассказать об автоматизации сетевых задач. Основной месседж я вынес в заголовок: «автоматизируй когда можешь, программируй когда необходимо».
После прочтения статьи Мэтта я бы даже уточнил эту формулировку: «автоматизируй, когда можешь, пиши скрипты, когда необходимо». Такая формулировка адресована именно сетевым инженерам (обратите внимание: именно эту мысль я вкладываю и в заглавную формулировку, но слово «скрипт» немного ее конкретизирует). В данном случае я перефразирую старую поговорку инженеров-сетевиков: «коммутируй, когда можешь, маршрутизируй, когда необходимо».

Автоматизируй, когда можешь

Эта формулировка подразумевает, что следует пользоваться подходящими инструментами, когда сетевая автоматизация возможна. Зачем изобретать велосипед, если он уже есть? Сейчас я сужу несколько предвзято, но рекомендую использовать какой-либо расширяемый инструментарий, лучше опенсорсный, который обеспечивает сетевую автоматизацию. В настоящее время я предпочитаю Ansible от Red Hat и StackStorm от Extreme. Однако, с тем же успехом можно воспользоваться и другими свободными инструментами, например, Puppet, Chef или SaltStack, либо даже коммерческими решениями от таких производителей как Cisco, VMware, Arista — добавьте вашего любимого производителя. В идеале вы (ваша команда сетевиков) должна 80% времени заниматься автоматизацией.

Программируй, когда необходимо

Программируй, когда необходимо, сейчас правильнее говорить — пиши скрипты, когда необходимо, то есть, когда используемый инструмент оказывается слишком сложен для выполнения некоторой операции. Тогда пишем скрипт для решения этой задачи, а, создавая этот скрипт — вы, возможно, достраиваете выбранный вами инструмент. В Ansible под скриптингом понимается создание собственного модуля или доработка имеющегося, либо программирование собственного фильтра Jinja2. Это НЕ забористое программирование, требующее многолетнего обучения и практики. Можно запрограммировать в виде скрипта очень интересные вещи, и на все про все потребуется 30-40 строк кода (может быть, чуть больше или чуть меньше). Речь не идет о том, чтобы написать 1000 строк кода. В идеале вы (или ваша команда сетевиков) должны тратить на программирование 20% времени.

Обратите внимание: в последнем предложении я упомянул именно «программирование», так как если у вас в команде есть штатные сценарщики, то они обязательно должны постараться дорасти до настоящих программистов.

Правило 80/20 при сетевой автоматизации

Если рассмотреть современную команду сетевых инженеров, то в сухом остатке возвращаемся к правилу 80/20. Если у вас в команде 10 человек, то 8 из них должны ежедневно пользоваться основным рабочим инструментом. Если их ~7 — тоже вполне нормально. Задача освоить инструментарий для управления продакшен-средой – сама по себе не из легких, поэтому тем более нельзя требовать от всех членов команды, чтобы они писали полноценный продакшен-код. Естественно, среди этих 7-8 человек найдутся те, кто будет писать скрипты активнее коллег – это реальность.

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

Наутро стать экспертом?

Кому-нибудь удавалось за ночь подготовиться к сложному экзамену на сетевой сертификат? Ага, никому. Я часто приравниваю их к CCNA, CCNP и CCIE. Учил ли кто-нибудь BGP как CCNA? Готов поспорить: если вы зададите вопрос о BGP кому-либо, только что сдавшему CCNA, он выдаст вам все, что знает о BGP — в полной уверенности, что этого достаточно. После этого ваш собеседник может открыть CCNP-справочник по маршрутизации и осознать, что ему еще учиться и учиться; при подготовке к CCIE его ждет то же самое. Кстати, самое интересное начнется, когда придется управлять продакшен-средой по протоколу BGP.

Итак, вы – системный администратор, желающий подучиться автоматизации и программированию? Шикарная идея! Берите и учитесь, только не пытайтесь подготовиться к CCIE к завтрашнему утру. Начинайте со скриптиков, разберитесь с типами и форматами данных!

Выводы об автоматизации сетевых задач

Первым делом, учтите, что здесь нет однозначно верного или ошибочного пути. Просто нужно сделать несколько ключевых выводов:

Памятка сетевого инженера.

  • Если вы только начинаете заниматься автоматизацией – поэкспериментируйте с несколькими инструментами и выберите из них один. Далее работайте именно с ним.
  • Независимо от того, с каким именно инструментом вы работаете – вам необходимо понимать типы данных. Это не программирование. Хорошо, если вы подмечаете фигурные скобки, но это все равно не программирование.
  • Независимо от того, с каким инструментом вы работаете, вы должны разбираться в форматах данных, например, понимать JSON.
  • Вы должны понимать, как пишутся скрипты, если a) нужно выполнить какую-то операцию, с которой ваш инструмент нормально не справляется, или b) исправить неполадки (рассмотреть трассировку стека), или c) расширить возможности вашего инструмента так, чтобы он стал справляться с новой задачей, которую ранее не мог выполнять, причем, эта задача легко внедрялась в ваши рабочие потоки. Такая работа ценна тем, что теперь и ваши коллеги по команде смогут воспользоваться ваши плагином, ничего не программируя для этого самостоятельно.

Заключение

Постарайтесь не смешивать собственное самообучение и работу по управлению продакшен-окружениями. Нет смысла писать ПОЛНОЦЕННЫЙ инструмент с нуля (все кроме API и/или клиентской части), если у вас нет на это нескольких штатных программистов, которые будут заниматься такой работой в режиме фултайма. А даже если есть — разве это оптимальный подход? Если подобные мысли вас уже посещали – то почему бы не воспользоваться (готовыми) опенсорсными инструментами?

Удачи с автоматизацией!

Джейсон
Only registered users can participate in poll. Log in, please.
Актуальность темы
96.23% Да, книга интересна, переводите 102
0% Нет, уже есть более внятные книги и по DevOps, и по администрированию 0
3.77% Лучше нечто подобное, но короче и практичнее 4
106 users voted. 20 users abstained.
Tags:
Hubs:
+12
Comments 3
Comments Comments 3

Articles

Information

Website
piter.com
Registered
Founded
Employees
201–500 employees
Location
Россия