Від SysAdmin до DevOps: частина II. Думки про мій власний переході (або про речі, які я хотів би знати заздалегідь...)

27 липня
Хебер Бенітес, DevOps
Від SysAdmin до DevOps: частина II. Думки про мій власний переході (або про речі, які я хотів би знати заздалегідь...)

Згідно з Вікіпедією, «DevOps — це набір методів, який об’єднує розробку програмного забезпечення (Dev) та операції з IT (Ops)». Але мені здається, що насправді, це культурний рух, метою якого є пожвавлення розробки, тестування та впровадження програмного забезпечення. У цій статті розповім про шлях, який я пройшов, щоб стати DevOps.

ЯК ВСЕ ПОЧИНАЛОСЬ

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

Від SysAdmin до DevOps image
Від SysAdmin до DevOps image

Через деякий час я познайомився з 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-системою для мережі аптек. Цей досвід змусив мене кардинально змінити свою точку зору: це були круті люди з абсолютно іншим підходом до життя. Я не кажу, що це краще чи гірше, просто інакше, і це змусило мене дивитись на речі інакше.

Від SysAdmin до DevOps image

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

З технічної точки зору цей досвід познайомив мене з GitLab, і я звик до термінів «комміт», «пуш», «злиття» тощо. Я навчився використовувати MySQL, дізнався, що RFC для протоколу HTTP є таким само складним, як і архітектура готичного собору, і що кожен браузер має що сказати. Я дізнався, що Amazon займався не лише продажем книг, і що з методологічної точки зору Agile нам дано для порятунку... А Docker — це просто диво!

ДЕ МОЇ СЕРВЕРИ?

Досягнувши певного ступеня зрілості, я почав працювати керівником команди обслуговування інфраструктури. Це був чудовий досвід! Я завершив багато задач і здебільшого все йшло за планом. Однак світ не стоїть на місці.

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

Від SysAdmin до DevOps image

У глибині душі я знав, що мені потрібно було рухатись далі та залишити свою зону комфорту, хоча мені дійсно подобалося жити в моєму виключно технічному світі. В одну мить я опинився на позиції 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 і 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 — методологія, а не назва посади. І шлях переходу непростий: іноді він може бути занадто довгим, звивистим і йти угору. Мені дуже хочеться поговорити про ваше місце наприкінці такого шляху, уявляючи, що воно має бути прекрасним. Але правда в тому, що я не вірю в існування фінішної межі. Навчіться насолоджуватися шляхом, який, як і наше уявлення про Всесвіт, є нескінченним.