Останнім часом такі оголошення заполонили інтернет. Незважаючи на приємну зарплату, не може не бентежити, що всередині написана дика брехня. Спочатку передбачається, що "DevOps" та "інженер" можна якимось чином склеїти разом в одне слово, а далі йде рандомний список вимог, частина яких явно скопійована з вакансії сісадміну.
У цьому пості хочеться трохи поговорити, як ми дійшли до життя такого, що таке DevOps насправді і що тепер із цим робити.
Такі вакансії можна всіляко засуджувати, але факт залишається фактом: їх багато, і так влаштований ринок на даний момент. Ми зробили девопс-конференцію та відкрито заявляємо: « - Не для DevOps-інженерів». Тут багатьом здасться дивним і диким: чому люди, які роблять комерційний захід, йдуть проти ринку. Зараз все пояснимо.
Про культуру та процеси
Почнемо з того, що DevOps це не інженерна дисципліна. Почалося все з того, що поділ, що історично склався, по ролях не працює на якість продуктів. Коли програмісти лише програмують, але нічого не хочуть чути про тестування, софт завалений багами. Коли адмінам начхати, як і чому написаний софт — підтримка перетворюється на пекло.
Наприклад, опис різниці між сисадмінським і SRE-шним підходом до service management . Цікаві дослідження проведено у рамках — видно, що найкращі розробники якимось чином примудряються деплоїти нові зміни на продакшн швидше, ніж раз на годину. Вони ж тестують руками не більше 10% (це видно по ). Як у них це виходить? «Excel or die» – каже один із заголовків звіту. За детальним обговоренням цієї статистики у розрізі тестування можна звернутися до кейноуту Баруха Садогурського на іншій нашій конференції, Heisenbug.
«Коли у товаришах згоди немає,
На лад їхня справа не піде,
І вийде з нього не діло, тільки мука.
Одного разу Лебідь, Рак та Щука…»
Як думаєте, яка частина веб-програмістів дійсно розуміє, в яких умовах експлуатуються їхні програми на продажі? Скільки з них піде до адмінів і намагатиметься розібратися, що станеться під час падіння бази? А хто з них вирушить до тестувальників та попросить навчити, як правильно писати тести? А там ще є безпечники, менеджери продуктів, ще купа людей.
Загальна ідея DevOps у тому, щоб налагодити взаємодію між ролями та відділами. Насамперед це досягається не якимось хитро налаштованим софтом, а практикою спілкування. DevOps – це про культуру, практику, методологію та процеси. Не існує такої інженерної спеціальності, яка б відповідала на ці запитання.
Замкнуте коло
Звідки взялася тоді дисципліна «девопс-інженерії»? Ми маємо версію! Ідеї DevOps виявилися гарними — настільки гарними, що стали жертвами свого успіху. Навколо цієї теми почали клубитися якісь каламутні рекрутери і торговці людьми, у яких дуже своя атмосфера.
Уявіть: учора ви в Хімках лудили шаурму, а сьогодні ви вже велика людина, сеніор рекрутер. Тут цілий процес пошуку та відбору кандидатів, все непросто, треба розуміти. Припустимо, начальник відділу каже: знайди спеціаліста з X. Приписуємо до X слово «інженер», і річ у капелюсі. Потрібний Linux? Ну це точно Linux-інженер, хочеш DevOps - DevOps-інженер. Вакансія складається не тільки із заголовка, а й усередині потрібно вписати якийсь текст. Найпростіше — вписати набір кейвордів із Гугла, кому скільки вистачить фантазії. DevOps складається з двох слів - "Dev" і "Ops", отже, треба склеювати кейворди, що належать до розробників та адміністраторів, все в одну купу. Так з'являються вакансії про володіння 42 мовами програмування та 20 років використання Kubernetes та Swarm одночасно. Робоча схема.
Таким у свідомості людей укоренився безглуздий і нещадний образ супергероя-«девопса», який налаштує всім деплою на Jenkins, і настане щастя. Ах, якби все було так просто. "А ще так можна хантити сисадмінів, - думає ейчар, - слово модне, кейворди ті ж самі, повинні клюнути".
Попит народжує пропозицію, і на всі ці треш-вакансії налетіла шалена кількість сисадмінів, які збагнули: можна робити те ж саме, що й раніше, але отримувати в кілька разів більше, назвавшись «девопсами». Як ти налаштовував сервер через SSH руками по одному, так і продовжиш налаштовувати, але тепер це нібито девопс-практика. Це якесь складне явище, частково пов'язане з недооціненістю класичних адмінів, і з хайпом навколо DevOps, але загалом — що вийшло, те вийшло.
Отже, у нас є попит та пропозиція. Замкнене коло, яке підживлює саме себе. Ось із цим ми й боремося (у тому числі, створюючи конференцію DevOops).
Безумовно, окрім сисадмінів, що перейменувалися у «девопси», є й інші учасники — наприклад професійні SRE або розробники Infrastructure-as-Code.
Чим люди займаються в DevOps (насправді)
Отже, ви хочете просунутися у вивченні та застосуванні практик DevOps. Але як це зробити, в який бік дивитися? Очевидно, сліпо керуватися популярними ключовими словами не варто.
Якщо робота є, хтось їй має займатися. Ми вже з'ясували, що це не девопс-інженери, тоді хто? Здається, правильніше сформулювати це над термінах посад, а термінах конкретних напрямів роботи.
По-перше, можна займатися самим серцем DevOps – процесами та культурою. Культура — справа нешвидка та нелегка, і хоча це традиційно сфера відповідальності керівників, так чи інакше в цьому беруть участь усі, від програмістів до адмінів. Кілька місяців тому Тім Лістер :
«Культура задається основними цінностями організації. Зазвичай люди цього не помічають, але ми, працюючи в консалтингу багато років, звикли це помічати. Ти заходиш у компанію і буквально за кілька хвилин починаєш відчувати, що відбувається. Ми називаємо це «ароматом». Іноді цей аромат справді добрий. Іноді він викликає нудоту. (…) Ти не можеш змінити культуру до того, як були усвідомлені цінності та переконання, що стоять за конкретними діями. Поведінку спостерігати легко, а шукати переконання складно. DevOps — це чудовий приклад того, як все стає складніше і складніше».
Є й технічна частина питання, звісно. Якщо у тебе новий код на тестування потрапляє через місяць, а в релізі виявляється лише через рік, і прискорити все це фізично неможливо – до добрих практик можна не дожити. Хороші практики підтримуються добрими інструментами. Наприклад, тримаючи в голові ідею Infrastructure-as-Code, можна використовувати будь-що, від AWS CloudFormation та Terraform до Chef-Ansible-Puppet. Все це треба знати і вміти, і це вже цілком інженерна дисципліна. Важливо не плутати причину зі наслідками: спочатку ви працюєте за принципами SRE і лише потім вже втілюєте ці принципи як якихось конкретних технічних рішень. При цьому SRE це дуже комплексна методологія, яка розповідає не про те, як налаштувати Jenkins, а про п'ять основних принципів:
- Поліпшення взаємодії між ролями та відділами
- Ухвалення помилок як невід'ємної частини роботи
- Поступове здійснення змін
- Використання тулінгу та іншої автоматики
- Вимірювання всього, що можна виміряти
Це не просто якийсь набір тверджень, а конкретне . Наприклад, на шляху прийняття помилок потрібно буде розібратися з ризиками, виміряти доступність та недоступність сервісів за допомогою чогось на зразок SLI () та SLO (), навчитися писати постмортеми і зробити так, щоб писати їх було не страшно.
У дисципліні SRE використання інструментів — лише одна з частин успіху, проте важлива. Нам потрібно постійно розвиватися у технічному плані, дивитися, що відбувається у світі і як це можна застосувати у своїй роботі.
У свою чергу зараз стали дуже популярними рішення Cloud Native. Згідно з сучасним розумінням Cloud Native Computing Foundation, технології Cloud Native дозволяють організаціям розробляти та запускати масштабовані програми в сучасних динамічних середовищах, таких як публічні, приватні та гібридні хмари. Як приклад можна навести контейнери, сервіс-міші, мікросервіси, незмінну інфраструктуру та декларативні API. Всі ці техніки дозволяють слабозв'язаним системам залишатися еластичними, керованими і добре спостерігаються. Хороша автоматика дозволяє інженерам робити великі зміни часто і з передбачуваними результатами, не перетворюючи це на пекельну працю. Все це підтримується стеком з усіх відомих інструментів, таких як Docker та Kubernetes.
Це досить непросте і розлоге визначення пов'язане з тим, що область досить непроста. З одного боку, стверджується, що нові зміни до цієї системи повинні додаватися досить просто. З іншого боку, щоб розібратися в тому, як зробити якесь контейнеризоване середовище, в якому слабко пов'язані сервіси живуть на software-defined інфраструктурі і поставляються туди за допомогою безперервного CI/CD, і побудувати навколо цього DevOps-практики — на цьому треба не одну собаку з'їсти.
Що з усім цим робити
Кожен вирішує ці проблеми по-своєму: наприклад, можна публікувати нормальні вакансії, щоб розірвати замкнене коло. Можна розібратися, що означають слова типу DevOps і Cloud Native і використовувати їх правильно і по справі. Можна розвиватися в DevOps та своїм прикладом демонструвати правильні підходи.
Ми ж робимо конференцію , яка надає можливість глибше розібратися у речах, про які ми щойно поговорили. Для цього є кілька груп доповідей:
- Процеси та культура;
- Site Reliability Engineering;
- Cloud Native;
Як вибрати, куди йти? Тут є тонкий момент. З одного боку, DevOps це про взаємодію, і нам дуже хочеться, щоб ви сходили на доповіді з різних блоків. З іншого боку, якщо ви керівник розробки, який прийшов на конференцію, щоб сконцентруватися на одному конкретному завданні, то ніхто вас не обмежує — очевидно, це буде блок про процеси і культуру. Не забувайте, що після конференції у вас залишаться записи (після заповнення форми зворотного зв'язку), тому ви завжди зможете переглянути менш важливі доповіді пізніше.
Очевидно, що на самій конференції ви не можете піти одразу на три треки одночасно, тому ми так формуємо програму, щоб у кожному часовому слоті були теми на будь-який смак.
Залишилося тільки зрозуміти, що робити, якщо ви DevOps інженер! По-перше, спробуйте визначити, чим насправді ви займаєтесь. Зазвичай цим словом люблять називати:
- Розробників, які займаються інфраструктурою. Для вас найбільше підійдуть групи доповідей про SRE та Cloud Native.
- системних адміністраторів. Тут важче. DevOops - не про системне адміністрування. На щастя, на тему системного адміністрування є безліч прекрасних конференцій, книг, статей, відео в інтернеті тощо. З іншого боку, якщо вам цікаво розвиватись у плані розуміння культури та процесів, вивчення хмарних технологій та подробиць життя з Cloud Native, то ми будемо раді вас бачити! Подумайте ось про що: ось ви займаєтеся адмінством, а далі що ви робитимете? Щоб несподівано не опинитися в неприємній ситуації, варто вчитися вже зараз.
Є ще один варіант: ви наполягаєте і продовжуєте стверджувати, що є саме DevOps-інженером і ніяк інакше, хоч би що це означало. Тоді змушені засмутити, DevOops це конференція не для DevOps-інженерів!
Слайд із у Мюнхені
DevOops 2020 Moscow пройде 29-30 квітня у Москві, квитки вже можна .
Крім того, ви можете до 8 лютого. Зверніть увагу, що при заповненні форми ви повинні вибрати цільову аудиторію, якій ваша доповідь принесе більше користі (усередині списку зарито сюрприз).
Джерело: habr.com