От SysAdmin к DevOps: Часть II. Мысли о моем собственном переходе (или о вещах, которые я хотел бы знать заранее...)

27 июля
Хебер Бенитес, DevOps
От SysAdmin к DevOps: Часть II. Мысли о моем собственном переходе (или о вещах, которые я хотел бы знать заранее...)
Согласно Википедии, «DevOps — это набор методов, который объединяет разработку программного обеспечения (Dev) и операции с IT (Ops)». Но мне кажется, что, на самом деле, это — культурное движение, цель которого — оживление разработки, тестирования и внедрения программного обеспечения. В этой статье рассажу о дороге, которую прошел, чтобы стать DevOps.

Как все начиналось

Когда мне было 14 лет, у меня появился первый компьютер. Это был Commodore 64, и первое, что я сделал — закричал: «LOAD!» — потому что хотел поиграть в игру с кассеты. Кто бы мог подумать, что этот момент навсегда изменит ход моей жизни? Через несколько месяцев и бесчисленных «как?» и «почему?» родители записали меня на компьютерные курсы. А через несколько лет я начал изучать системную инженерию в университете.

pic
pic

Через некоторое время я познакомился с Windows95, с SuSE Linux — когда это было бесплатно — и, в конце концов, с интернетом!

Когда мне исполнилось 19, я пошел на работу, совершенно на связанную с программированием. Как и для многих из нас, моя первая работа не имела ничего общего с тем, что я хотел делать, — я работал слесарем. В итоге я занялся проектированием конструкций для водопроводных систем, а в дальнейшем работал в управлении производством.

Оборудование, операционные системы, сеть и системы хранения данных

Под лежачий камень вода не течет. В конце концов, судьба привела меня в IT-индустрию, где я начал работать сисадмином. Здесь я рассуждал о сокетах, TCP/IP — IPX... Да, я познакомился с Novel Netware, с известным каталогом SYS — и с компьютеризированной пакетной обработкой, в огромной коробке с надписью IBM AS400. Меня попросили изучить NT и сертифицировать нечто под названием Windows 2000. Я также создал скрипт — мое волшебное слово! — для пользователей LDAPv3.

Я узнал, что могу получить доступ к любому компьютеру без разрешения, и что более важно: что кто угодно может получить доступ к моему компьютеру. Безопасность — это очень важно!

Я также узнал, что мне есть чем делиться с другими, и решил сменить работу — внимание, спойлер: я сделал много изменений в профессиональной жизни, даже сейчас у меня снова переходный период. Мой путь — потрясающий опыт. Мне довелось повидать гипервизоры и распределенные системы, блэйд-серверы, пережить обновление харда, использовать витую пару UTP Cat 4 и 5, установить и настроить SAN и NAS, настроить разные уровни RAID, кластеры, балансировщики 4-го уровня, прокси и систему проверки пакетов.

В конце концов я понял, что все должно быть организовано, и я имею в виду не только IT-сервисы, но и процессы и процедуры: должна быть политика, устанавливающая границы.

Проектная команда против «тех ребят»

Одной из моих первых задач в качестве системного администратора было информировать моего руководителям по вопросам продакшена. Т. к. у нас была операционная система Windows, я использовал VBS и сайт под названием: «Эй, чувак по созданию скриптов», и я написал замечательный код. Но это отличалось от прикладного кодирования, и я начал задумываться: в чем именно разница между задачами DevOps и скриптами, которые я создаю?

До тех пор единственное, что я знал наверняка: отчасти именно «благодаря» разработчикам с операционной средой появлялись проблемы. Другими словами, это человек, которому ты практически по умолчанию говоришь «нет». На самом деле все работает гладко, пока на горизонте не появится разработчик с очередным обновлением для твоего приложения, которое рвет в клочья все SLA, KPI и любые другие метрики.

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

Само собой, администраторы тоже в стороне не оставались: иногда мы забываем настраивать определенные порты, и пользователи оказывались в шоке от кучи сообщений OLEDB.

От ServerFault к StackOverflow

Моя следующая работа была связана с оказанием прямой поддержки группе разработчиков, работающих над ERP-системой для сети аптек. Этот опыт заставил меня кардинально изменить свою точку зрения: это были крутые люди с совершенно другим подходом к жизни. Я не говорю, что это лучше или хуже, просто по-другому, и это заставило меня смотреть на вещи по-другому.

Я многому у них научился. Например, программирование — это гораздо больше, чем просто написание кода. Это понимание требований бизнеса, ответственность за каждый релиз, сбор данных (при необходимости) и затем тестирование, работа с виртуальными машинами, внесение изменений в последнюю минуту, потому что пользователь забыл что-то добавить, соблюдение дедлайнов, даже когда узнаешь, что есть ошибка, которую нужно исправить, общение с системными администраторами, чтобы они «позволили тебе» добавить что-то в их среде — это означает, что люди говорят: «Мы так боимся», — до того, как ты введешь обновление в производство, люди критикуют твой код (по сути — твое чадо!), и множество командной работы.

С технической точки зрения этот опыт познакомил меня с GitLab, и я привык к терминам «коммит», «пуш», «слияние» и т. д. Я научился использовать MySQL, узнал, что RFC для протокола HTTP так же сложен, как и архитектура готического собора, и что каждому браузеру есть что сказать. Я узнал, что Amazon занимался не только продажей книг, и что с методологической точки зрения Agile нам дан во спасение... А Docker — это просто волшебство!

Где мои серверы?

Достигнув определенной степени зрелости, я начал работать руководителем команды обслуживания инфраструктуры. Это был замечательный опыт! Я завершил много задач и, как правило, все шло по плану. Однако мир не стоит на месте.

Технологии развивались рука об руку с экономической глобализацией, и жизнь в сети становилась все более важной. Мобильные приложения были самой горячей тенденцией, возникла новая проблема под названием C10k, Интернет пострадал от множества DDOS, и все говорили о CDN — или, по крайней мере, я говорил. Из своей зоны комфорта я думал, что этот «внешний мир» — электронной коммерции, скорости, HTTP, www, балансировки нагрузки уровня L7, API, мобильных телефонах и т. д. — сильно отличался от моего «внутреннего мира» — DHCP, сеть периметра, кластера SQL Server, пользователи, персональные компьютеры и интранет.

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

Я был очень хорошо знаком со всеми столпами IT-инфраструктуры, умел программировать, обладал опытом в среде разработки, знал принципы процессов, безопасности информации и данных, знал, как создавать надежные решения, и многое другое. «Да я просто мастер!» — думал я с огромной уверенностью и самодовольной улыбкой (которую до сих пор не могу обрести).

Как вы можете себе представить, все оказалось совсем по-другому. Первое, что пришло мне в голову: «Где мои серверы? Где инвентаризация? Где схемы?» И то, что последовало, было еще хуже. Дымовое тестирование? Endpoint? Архитектура? (Кажется, я начинаю понимать! О, нет... Подразумевалось что-то под названием «управляемая событиями архитектура»... ладно, ладно…

Было слишком поздно, когда я понял, что совершил огромную ошибку: в зависимости от подхода к бизнесу, обычным подходом DevOps был CI, и это был совершенно другой мир! И я говорю «обычный», а не «регулярный», потому что иногда это может означать, например, подход с использованием облачной инфраструктуры: разрешение на использование TCP/UDP-порта, перенастройка AutoScaling или исправление любых неправильных настроек. Другими словами, вы просто не хотите работать с разработчиками.

С другой стороны, у меня был опыт работы с микросервисами, однако я никогда не работал с методологией непрерывного развертывания. Я обнаружил, что небольшие релизы ПО работают лучше, чем меньшее количество более крупных внедрений. Для этого вся команда должна быть хорошо подготовлена; в конце концов, мы должны быть уверены, что это событие не повлияет на продакшен, верно?

Некоторые особенности:

  • Повсюду теги: Я могу присвоить тег группам объектов, а затем легко обратиться к ним из другой системы. Здорово!
  • Бессерверные и пакетные вычисления. Чудесно!
  • Инфраструктура как код. Мне никогда не нравилось марать руки добавлением дополнительной памяти. Прелестно!

Я помню, как будто бы это было вчера: во время моего первого звонка клиент сказал мне: «Просто сохраните артефакты на Artifactory». Я понятия не имел, о чем он говорит! Испанский — мой родной язык, и я приложил немало усилий, чтобы понять значение английского слова «артефакт». Преодолев этот первый основной барьер, я попытался выяснить, где находятся эти артефакты и какие процессы создаются. Как только я нашел это в определенном каталоге в контейнере Docker — в GitLab он называется Runner — я получил URL.

Даже не зная, что URL отличался от Endpoint (опять же, только с точки зрения программирования: REST против NON-REST), я скопировал его в адресную строку моего любимого браузера, ожидая запроса на вход. Но я получил данные в формате JSON: «Отказано в доступе». Ошибка новичка. Мне потребовалось время, чтобы понять, что такой доступ предоставляется только по пайплайну GitLab.

Другие задачи, которые действительно меня шокировали:

  • Скриптинг на YAML и HCL.
  • Понимание GO, IOS и даже Java!
  • Создание пайплайна, даже не зная, как каждый язык взаимодействует с процессом тестирования.
  • Понимание всей инфраструктуры на основе Terraform, неразрывно связанной с сотнями ветвей разработки, обладая скудными знаниями о графическом интерфейсе AWS.
  • Создание схемы независимых задач между Lambda, SNS, Slack и Datadog, не зная, что это такое.

Должен признать, что не раз в моей голове появлялась старая добрая мысль: «Этим занимаются разработчики, просто сделай для них тикет». Но теперь это было то, чем занимался я. Внезапно я снова оказался на уровне джуниора.

Немного противоречий

Я открываю новую тему: дорога к DevOps кажется немного более милосердной и мягкой, когда путник начинает с основ программирования. Зачем я это говорю?

  • Прежде всего, потому что разработчик, скорее всего, уже знает, что означает работа с пайплайном программного продукта. Например, как создать скрипт.
  • В один день можно узнать, как работает балансировщик нагрузки; на следующий день — о его протоколах и RFC; на третий день — применить это на практике. Но нельзя так же быстро научиться писать код.
  • Фаза непрерывной интеграции разделяет многие элементы с тестированием ПО и контролем качества, которые не принадлежат к операционному миру — по крайней мере, строго говоря, кто-то может утверждать, что IaC может быть использован для развертывания, и это абсолютно нормально.
  • В мире, где большинство сервисов связано с интернетом, неудивительно, что у разработчика есть опыт в высокодоступных сервисах или сервисах веб-сайтов. Это могло бы привести его к исследованиям на L4 и L7, автоматическому масштабированию, мониторингу; и привести его к созданию VPC и организации подсетей.
  • Что касается систем, неудивительно, что разработчик взаимодействует с разрешениями файловой системы, с пользователями, с правилами брандмауэра и даже с ядром ОС посредством Sysctl.
  • Если мы говорим об облаке, все больше и больше предприятий и стартапов используют облачные сервисы. На нижнем уровне можно найти IaaS, который позволяет управлять хранилищем, компьютерными системами, сетью и т. д., прокладкой кабелей и хранением серверов, зная, что RAID и система охлаждения уже не важны, значение IOPS для системы хранения уже перестало быть необходимостью, и мне пора уже перестать беспокоиться о трафике в BGP и шифровании данных в покое. Все, что нужно, — строчка кода!
  • Что касается автоматизации, 15-20 лет назад мы не могли найти такого разнообразия инструментов, как сегодня: среди них Chef, Puppet, Ansible. Также мы можем найти «бессерверный». Например: LAMP Serverless позволяет развернуть код в производство, не беспокоясь о мощностях, управлении и планировании конфигурации, которые не имеют отношения к бизнесу. Поэтому разработчик в основном ориентируется на результат. Я думаю, что этот подход в будущем будет только развиваться, но об этом мне нужно будет написать отдельную статью.
  • Самый спорный вопрос — это все навыки, которые необходимо освоить DevOps: язык программирования/команд; Go, Python, Java, PHP, C#, HTML, CSS, JavaScript; Kubernetes and Swarm; контейнера и облачные вычислительные сервисы, такие как AWS, GCP, Azure; системы управления кодом, такие как GitHub и CI, такие как GitLab; развертывание с использованием Ansible, Puppet или Chef; администрирование Linux и Windows; балансеры и кластеры; кэширование базы данных; криптография TCP, UPD, DNS, HTTP; SSL/TLS; такие базы данных как MySQL, MSSQL, MongoDB, Redis, Casandra, Aurora; инфраструктура как код: Terraform или Cloud Formation; инструменты мониторинга, такие как New Relic, Datadog, Nagios, Zabbix. Кроме того, DevOps необходимо постоянно учиться работать с огромным количеством информации. Похоже, что один человек отвечает за задачи всего системного отдела!

Заключение

Существует не только дин план перехода, потому что путей столько же, сколько людей в мире. Каждый человек уникален, обладает собственными качествами, и поэтому я думаю, что в списке терминов «непрерывная интеграция», «непрерывная доставка» и «непрерывное развертывание» не хватает четвертого понятия, которым было бы «непрерывное обучение».

Я знаю, что процесс обучения должен быть как можно более агностичным, однако иногда необходимо детально изучить конкретный продукт и проинструктировать новых сотрудников, и мне кажется, что направить их по этому пути — значит принести пользу бизнесу; при этом очень важно знать технологический процесс, сеть и диаграмму сервисов.

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