Як розробнику «влитися» в тему DevOps



Сьогодні ми вирішили поглянути на ситуацію з Java і Python-розробником, який задумався про «зануренні» в тему DevOps в той момент, коли він почав все більше віддалятися від звичних інструментів на користь роботи з Oracle Weblogic і shell-скриптами. Він вирішив поєднати свій досвід в області розробки з новим досвідом в роботі з процесами.

Ми подивилися на основні поради експертів в області DevOps на Quora і доповнили розповідь прикладами з досвіду команди 1cloud.


Джонатан Феноччи (DevOps розробник у Bazaarvoice): Мені дуже подобається працювати у сфері хмарних технологій і займатися темою DevOps. Часто цей термін використовують, щоб описати системних програмістів (іноді також називають інфраструктурними розробниками, системними розробниками, розробниками процесів (операцій), або, самим невідповідним способом, системними адміністраторами).

DevOps означає зовсім не це, але в контексті кар'єрного зростання, у цих визначеннях відбивається розуміння того, чим займається «сучасний» системний програміст.

Отже, ти розробник і хочеш перейти до роботи з процесами. Тут тебе чекає сюрприз. Весь сенс не в тому, щоб встановити Arch Linux і почати вивчати Perl. Для подібного роду речей існує певне місце (дуже маленьке і темний у найвіддаленішому кутку нашої всесвіту), але для початку давай визначимося, що представляє із себе DevOps, і чим він не є.

Що має на увазі під собою робота в області DevOps:

  • ЗА Розробку;
  • Розробку інструментів;
  • Інфраструктурне проектування;
  • Регулярне рішення складних завдань;
  • Масштабування, тому що воно необхідно;
  • *NIX;
  • Мониторонг;
  • Віртуалізація;
  • Бути на зв'язку при відключенні електрики в 2 години ночі;
  • Технічне обслуговування (наприклад, рішення проблеми з витоком пам'яті віртуального хоста);
  • Гнучка методологія розробки;
  • Цикли випуску та контроль за ними;
  • Автоматизація, автоматизація і знову автоматизація;
  • Метрики/звітність (йдуть паралельно з моніторингом);
  • Розробка плану по використанню гілок і релізів продукту для конкретних СУВ(SCM) (git, Mercurial, svn, ін);
  • ІБ;
  • Хмарні технології;
  • Оптимізація/тонка настройка;
  • Тестування і виміри рівня навантаження/продуктивності;
  • Управління конфігурацією (Puppet, Chef, Ansible, та інше);
  • Сервіси аутентификації;
  • Системи управління пакетами;
  • Вміння працювати з командним рядком (awk);
  • Балансування навантаження/ проксіювання (служб, систем, компонентів і процесів);
  • CI/CIT/CD — безперервна інтеграція, інтеграційне тестування і розгортання нових версій (deploy);
  • Бази даних (SQL, NoSQL, без різниці);
  • Впевнене знання систем (мережевого стека, жорсткі диски/файлові системи/системна пам'ять/процесор).
Що НЕ мається на увазі під роботою в області DevOps:

  • Простота (у порівнянні з розробкою ПЗ);
  • Відсутність необхідності програмувати;
  • Установка Linux і прощання з твоєї улюбленої ОС;
  • Набагато «цікавіше», ніж розробник ПЗ;
  • Абсолютно нова сфера роботи.
Потрібно зробити кілька речей, щоб почати позиціонувати себе як DevOps розробника.

Пройти інтерв'ю в компанії, якій потрібен DevOps. Якщо тебе візьмуть на роботу, то ти швидко навчишся роботі з процесами. Дуже швидко. Інакше тебе звільнять. Якщо тебе не звільнять, то ти зрозумієш, чого тобі не вистачає, щоб дійти до рівня повноцінного DevOps-розробника.

Отримати досвід роботи використовуючи свої навички розробника ПЗ для побудови інструментів, а не ЗА. Вивчити OpenStack. Важливо розуміти відмінність компонентів і їх важливість.

Брати участь у всіх процесах, пов'язаних з операціями: розгортання, масштабування і так далі. Якщо твоя команда не займається цим (наприклад, вони відсилають всі відділу працюють з операціями), потрібно звернутися до хлопців, які займаються операціями і подивитися за процесом декількох розгортання.

Потрібен значний досвід? Я задавав це питання собі безліч разів. Я починав з розробки, і менш ніж за рік роботи з операціями став DevOps-розробником. Я не мав помітними алгоритмічними здібностями, але досвід розробки у мене був пристойний. Хороший розробник хороший у всьому: і в написанні ПО, і в її розгортанні. Необхідно розуміння складності систем і інтуїтивне розуміння того, як вони впливають один на одного.

Ярослав Ворожко (DevOps розробник у Delivery Hero): За великим рахунком, DevOps зачіпає дуже широке коло знань, з яким складно і цікаво працювати.

Ось як виглядає моя звичайна робоча тиждень:

  • Розгортання (випуск ЗА і автоматизація розгортання на Fabric і Python);
  • Управління інцидентами (робота з виникаючими проблемами, написання відновних процедур і моніторинг);
  • Моніторинг, який знаходиться в експлуатації (Icinga, Newrelic, Munin, управління логами, наприклад, з допомогою Splunk);
  • Управління конфігурацією (Saltstack, Chef, Puppet і Ansible, весь стек служб, які необхідні для роботи програми);
  • Написання різних скриптів (з bash і python, робота з awk, sed, grep, sort, uniq, cat, cut, echo, fmt, tr, nl, egrep, fgrep, wc).
Ми вирішили навести пару прикладів з практики команди 1cloud.

Так, технологічний стек back-end розробника становить: .NET, C#, ASP.NET MVC, Visual Studio, Team Foundation Server.

З точки зору API, SDK: Vcloud SDK .NET, vSphere SDK .NET, NetApp Manageability SDK C#.

Управління інцидентами здійснюється з допомогою ServiceNow, для моніторингу використовується Zabbix. Для роботи з різними скриптами застосовується bash, PowerShell. В подальшому планується перехід на управління конфігурацією з допомогою Puppet.

Ось так виглядає список щоденних завдань адміністратора систем Microsoft:

  • Рішення користувальницьких інцидентів;
  • Виконання заявок користувачів;
  • Робота над поточними проектами (налаштування серверів на базі Windows Server для надання клієнтам сервісів: термінальні служби, MS SQL та інших);
  • Планування змін (складання планів перед проведенням робіт на серверах – ServiceNow);
  • Спілкування з вендорами з проблем у роботі з ПЗ;
  • Написання скриптів для автоматизації проведених робіт (PowerShell);
  • Аналіз подій від системи моніторингу (SCOM).
Базові обов'язки менеджера з інформаційної безпеки:

  • Моніторинг подій ІБ у Security Information and Event Management system (SIEM) AV USM, TrendMicro Deep Security, PaloAlto 2050, WAF ModSecurity;
  • Управління уразливими ІБ, проведення внутрішнього та зовнішнього сканування (OpenVAS на основі AV USM і Qualys);
  • Отримання ліцензії ФСТЕК на ТЗКИ і ФСБ «на криптографію» (атестація приміщення та Армів, збір та підготовка документів);
  • Проведення навчання працівників з питань ІБ;
  • Управління інцидентами (робота з виникаючими проблемами, написання відновних процедур і моніторинг).
p.s. Парочка додаткових матеріалів про роботу над нашим хмарним сервісом на Хабре:



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.