Перед тим, як ваш мозок почне обробляти суть методик та складати кострубаті (буде здаватися) пазли в цілісну картинку, майте на увазі: якщо ви зможете дочитати цю статтю до кінця і зрозумієте хоча б в загальних рисах що таке DevOps та хто такий SRE- інженер – вітання. You’ve got what it takes, щоб змінювати свою кар’єру.
Коли компанія вкорінена в ізольовану структуру, де розробка програмного забезпечення та операції працюють окремо, впровадження DevOps часто тягне за собою організаційну перебудову. Для успішного впровадження DevOps потрібні правильні люди, культура та інструменти. Проте, згідно з опитуванням Atlassian 2020 DevOps Trends Survey, однією з найпоширеніших перешкод для впровадження DevOps є брак потрібних навичок у співробітників.
Репетитор з програмування в Києві.
Однією з ключових ролей для впровадження реструктуризації DevOps є DevOps-інженер. Цей фахівець повинен володіти широким набором навичок, що охоплює як розробку, так і операції, а також якісні навички спілкування, щоб подолати розбіжності між відокремленими командами. Давайте ближче подивимось на девопсів, культуру, яку вони сповідують та все, що до неї дотичне.
Тут можна швидко почитати про спеціаліста, який виключно відповідає за комунікацію та організацію в ІТ.
Хто такий DevOps?
DevOps (Development and Operations) – це методика, спрямована на забезпечення ефективної взаємодії розробників та кінцевих користувачів продукту та оптимізацію всіх процесів життєвого циклу ПЗ.
DevOps – це набір практик, що поєднує розробку програмного забезпечення з його обслуговуванням і експлуатацією. Його назва відображає ці дві частини: Development and Operations (розробка та операції). DevOps виник із колекції попередніх практик. Серед них – система Agile development, Toyota Way та Lean manufacturing. Термін DevOps став широко відомий на початку 2010-х років.
Основна мета DevOps – скоротити час між тим, коли внесли зміни у код і тим, коли клієнт ці зміни відчув, не впливаючи при цьому на надійність продукту. Він/вона прагне узгодити цілі розвитку з потребами організації для створення цінності бізнесу.
Інженер DevOps – це ІТ-спеціаліст широкого профілю, який повинен мати грунтовні знання як у розробці, так і в різних операціях, включаючи кодування, управління інфраструктурою, системне адміністрування та ланцюжки інструментів DevOps. Інженери DevOps також повинні володіти навичками міжособистісного спілкування, оскільки вони працюють з різними командами компанії, щоб створити середовище для більш ефективної співпраці.
DevOps -інженери повинні добре розуміти загальну архітектуру системи, ініціалізацію та адміністрування. Також DevOps-інженер повинен мати досвід роботи з традиційним набором інструментів розробника та практиками, такими як:
- використовувати сорс контрол систему (Sourse Code Control System);
- надавати та отримувати огляду коду (Code Review);
- писати модульні тести;
- бути знайомим з принципами Аgile.
Якщо в цьому місці вам вже складно – почитайте про UX/UI дизайн. У цій професії не потрібно технічних знань!
Роль DevOps-інженера та його/її обов’язки
Роль інженера DevOps буде відрізнятися від компанії до компанії, але незмінно передбачає, що фахівець буде поєднувати розробку релізів, забезпечувати інфраструктуру та управляти нею; бути системним адміністратором, забезпечувати безпеку всього, що є на проєкті, та просувати філософію DevOps.
DevOps Engineer – це спеціаліст, який бере участь у всіх етапах життєвого циклу продукту. Цей фахівець забезпечує тісну кооперацію між командами розробників, щоб оптимізувати їхні робочі процеси і, відповідно, допомагає скоротити час, за який програмний продукт потрапить до кінцевого користувача.
Коли ми говоримо про DevOps-інженера потрібно розуміти, що цей фахівець не є якимось конкретним вузькопрофільним спеціалістом.
Є якась конкретна професія, яка плавно перетікає в DevOps? Ні. Ці фахівці приходять на посаду з різних професій. Наприклад, інженер DevOps може почати як розробник програмного забезпечення, який контролює аспекти ІТ-операцій. З іншого боку, інженер DevOps може бути в минулому системним адміністратором, оскільки він отримав знання про кодування, створення сценаріїв, інтеграцію та тестування. Робочі задачі інженера DevOps і SysOps можуть частково збігатися залежно від компанії та її технічних потреб. Але саме до обов’язків інженера DevOps входить зміна бізнес-процесів таким чином, щоб вирішити організаційні проблеми і покращати бізнес-результати.
Програмування онлайн тут.
Незважаючи на широкий і різноманітний діапазон ролей DevOps, є деякі загальні навички та вміння, на які вам потрібно звернути увагу, якщо ви націлені стати девопсом.
Ви повинні мати:
- досвід адміністрування ОС, таких як Linux і Windows;
- значний досвід роботи з рядом інструментів автоматизації та керування конфігураціями, такими як традиційні сценарії, а також більш специфічними інструментами, такими як Puppet і Chef;
- чітке розуміння програмування та створення сценаріїв поширеними мовами програмування, такими як PHP, Python, Perl і Ruby;
- знання принаймні однієї основної мови кодування, такої як C++ або Java;
- здатність ідентифікувати, оцінювати та інтегрувати різні технології з відкритим кодом , а також хмарні сервіси;
- серйозний досвід ІТ-апаратного забезпечення та роботи з практичним досвідом встановлення серверів, сховищ і мережевих пристроїв, ініціалізації та моніторингу. Це зазвичай доповнюється знаннями найкращих ІТ-практик для відмовостійких операцій з високою доступністю;
- здібності до підтримки команд та співпраці з ними, а також підтверджені навички взаємодії з клієнтами;
- грунтовне знання технологій віртуалізації, таких як VMware vSphere для віртуальних машин, а також досвід роботи з контейнерними технологіями, такими як Docker і Kubernetes;
- перевірений досвід роботи з інструментами CI/CD, такими як Microsoft GitHub, Atlassian Jira та Confluence, Red Hat Ansible, Prometheus та Jenkins;
- грунтовний практичний досвід роботи з публічними хмарними ресурсами та службами, такими як AWS, Microsoft Azure і Google Cloud;
- досвід роботи з різноманітними інструментами ІТ-моніторингу та управління, такими як Cloudflare і Datadog;
- знання про те, як усунути несправності та вирішити технічні проблеми в тестовому та робочому середовищах.
Вимоги до навичок девопса вражають, але дата саєнтисту теж непросто. Ще одна технічна професія саме для вас!
Програмування з нуля - реєструйтеся вже зараз!
SRE інженер − ще один важливий спеціаліст?
SRE (Site Reliability Engineering – розробка надійності сайту) SRE – це також методика, яка об’єднує програмне забезпечення та команди операцій з метою створення надійних, стійких і масштабованих систем.
Методололгію SRE розробив інженер Google Бен Трейнор Слосс у 2003 році. Метою Google було підвищення надійності своїх сайтів і служб. SRE досягає цієї надійності шляхом інтеграції найкращих практик розробки та проєктування в інфраструктуру та роботу послуг.
SRE часто розглядають разом із методикою DevOps. Порівнявши SRE з DevOps, ми побачимо, що вони мають однакові кінцеві цілі. Обидві методики намагаються привести розробку і операції у відповідність із задоволеністю клієнтів.
Простіше кажучи, SRE з DevOps втілюються, щоб розробка і надійність продукту виливалась в такий класний сервіс, що клієнт залишається абсолютно щасливим.
Однак їхні методи досягнення цих цілей відрізняються. У той час як DevOps зосереджується на об’єднанні розробки та операцій для підвищення цінності бізнесу, SRE зосереджується на, власне, процесі досягнення цих цілей. Ні SRE, ні DevOps не кращий один за інший, натомість обидві методики працюють разом.
Принципи SRE
- невдача неминуча, але ви завжди можете отримати з неї корисний досвід;
- зусилля, витрачені на підвищення надійності після точки зміни, яку клієнти помітять, це зусилля, які краще було б витратити в іншому місці;
- там, де це можливо, автоматизуйте виконання важких завжань;
- потрібно вирішувати інциденти, не звинувачуючи один одного – працювати разом, щоб знайти проблеми в системі, які призводять до помилок.
Якщо ви дісталися до SRE-інженера, можливо ви розглянете варіант роботи з штучним інтелектом?
Які цілі і задачі SRE-інженера?
Типовий процес роботи SRE-інженера – це скоріше набір найкращих практик, які включають:
- моніторинг даних для виявлення інцидентів: використовують засоби моніторингу, щоб збирати інформацію про роботу системи. Потім інженери використовують автоматичні сповіщення, коли відхилення виявлено;
- реагування на інциденти за допомогою таких інструментів, як runbooks: якщо щось піде не так, розробляють плани, щоб ефективно впоратися із ситуацією, і надають інформацію всім членам команди;
- створення ретроспектив інцидентів, щоб вчитися на інцидентах: кожного разу, коли SRE- інженер зазнає невдачі, він/вона документує процес та інформацію, яка її стосується. Таке документування дозволяє використовувати певну невдачу на свою користь в майбутньому;
- перетворення інцидентів у вплив на клієнта за допомогою SLI (Service-Level Indicator) та SLO (Service-Level Objectives): дивлячись на те, як клієнти використовують певні послуги, SRE- інженер може оцінити, який вплив мають інциденти на ці послуги, а отже і на користувача. Це дозволяє визначити порядок відповідей інженера на інциденти максимально ефективно;
- розробка на основі доступного бюджету помилок (Error Budget): SRE- інженер міркує, наскільки швидко він/вона рухаєтеся вперед із розробкою на основі аналізу ризику порушення SLO;
В ідеалі ці практики забезпечують дотримання принципів SRE і допомагають людям, які керують системами, дізнаватися більше, розвиватися та відчувати підтримку.
Мінісловничок
- Бюджет помилок (Error Budget) – це кількість помилок, які певний сервіс може накопичити за певний період часу, перш ніж користувачі цього сервісу будуть його ненавидіти.
- Service Level Indicator (SLI) – це кількісна оцінка роботи сервісу, як правило, пов'язана з тим, наскільки користувачі задоволені продуктивністю програми або сервісу за заданий період часу (місяць, квартал, рік).
- Service Level Agreement (SLA) – це угода між провайдером і клієнтом щодо вимірних показників, таких як час безвідмовної роботи, швидкість реагування сервісу та всю відповідальність, яку бере на себе провайдер.
- Service Level Objective (SLO) – це угода в рамках SLA щодо конкретного показника, наприклад часу безвідмовної роботи або часу відповіді сервісу.
Розробка надійності сайту (SRE) проголошує багато переваг для розподілених систем. SRE покращує автоматизацію інфраструктури, підвищує надійність і трансформує управління інцидентами. Однак перевага Site Reliability Engineering, про яку часто забувають, передбачає трансформацію культури самої компанії. Читаючи книгу Google Site Reliability Engineering, ви побачите, що SRE культура згадується в багатьох розділах. Але про неї говорять не так часто, як про навички девелоперів та процеси створення ПЗ.
Чому компанії ігнорують культурні зміни, які виникають завдяки розробці надійності сайту? Що ж, всіх нас навчили поважати технічні знання, а не навички спілкування та культуру людей. Особливо це стосується ІТ, де все ще кваліфікованих інженерів називають рок-зірками та ніндзя. Однак у підсумку, ми отримуємо культуру, яка ставить у центрі саме конкретну людину, а не команду.
Слабкий та вразливий продукт - це погано для бізнесу, але чи не гірше мати слабку роз’єднану організаційну модель, яка покладається лише на кількох фахівців?
Отже, яке рішення цієї проблеми? Для початку, окрім стимулювання змін у процесах, Site Reliability Engineering стимулює зміни в самій культурі компанії.
SRE приймає ризики, розповідає про важкі проблеми та вчиться на невдачах, не дозволяючи людському его заважати.
Реальність у нас наступна: за DevOpsами/SRE-інженерами ганяються, на них полюють і пропонують колосальні гроші, аби тільки отримати такого спеціаліста собі в компанію. Звичайно, треба мати клепку в голові і відповідати вимогам, бо якщо комусь здається, що він вже DevOps чи SRE- інженер бо він знає, як виглядає сервер і йому подобається, як він гудить і як блимають кнопки, або ще краще – може «змусити білочку стрибати по параболі» (хтось колись наводив мені такий приклад) – то ви трохи не в ті двері стукаєте.
Зважте також на навантаження та графік. Уявіть собі: шось зламалось підступно в кінці робочого дня, а ви працюєте з США і вам би вже пива і спати, а їм «гуд морнінг, Америка!» І вам, відповідно, треба все пофіксити, бо дітям треба гратися, пасочки ліпити а з пісочниці пісок висипається і лопатки зламані. От ви і сидите півночі, щоб не гальмувати робочі процеси багатьох людей. Бо ми ж вже з’ясували, що девопси то люди, які зв’язують команди, будують мости взаємодій та ефективності.
Поки ви вирішуєте, що вам дорожче: золотий запас чи здоровий сон і відсутність гіпертонії в 22 рочки, я вам скажу, що починати треба з програмування в будь-якому разі.
Удача посміхається вам! Крутіть барабан і обирайте кваліфікованого девелопера або репетитора з програмування на Superprof, який вже прямо зараз готовий вас вчити, і вперед до роботи! Воно того варте!
Вам сподобалась ця стаття? Оцініть її!
Loading...
