Мова, звичайно, про . Якщо не вдаватися до деталей, то 30 вересня та 1 жовтня ми проведемо конференцію про об'єднання процесів розробки, тестування та експлуатації, а якщо вдаватися — прошу під кат.
В рамках DevOps-підходу всі частини технологічного розвитку проекту переплетені між собою, відбуваються паралельно та впливають одна на одну. Особливої ваги тут набуває створення автоматизованих процесів розробки, які можна змінювати, моделювати і тестувати в реальному часі. Це допомагає миттєво реагувати на зміни на ринку.
На конференції хочемо показати, як впливає такий підхід на розвиток продукту. Як забезпечується надійність та адаптивність системи для клієнта. Як DevOps змінює структуру та підхід компанії до організації робочого процесу.
Закулісся
Нам важливо знати не тільки, що роблять різні компанії в рамках DevOps-підходу, але й розуміти, навіщо це все. Тому до складу Програмного комітету ми покликали не просто експертів, а фахівців, які бачать DevOps-дискурс із різних позицій:
- senior-інженерів;
- розробників;
- тимлідів;
- технічний директор.
З одного боку, це створює складнощі та конфлікти під час обговорення заявок на доповіді. Якщо інженеру цікавий розбір великої аварії, то розробнику важливіше зрозуміти, як створити софт, що працює у хмарах та інфраструктурах. Але домовляючись, ми створюємо таку програму, яка буде цінною та цікавою для всіх: від інженерів до CTO.
Завдання нашої конференції не просто вибрати доповіді похайповіше, але уявити загальну картину: як працює DevOps-підхід на практиці, на які граблі можна нарватися під час переходу до нових процесів. При цьому ми вибудовуємо контентну частину, спускаючись від бізнес-завдання до конкретних технологій.
Секції конференції залишаться тими самими, що й у .
- Інфраструктурна платформа
- Інфраструктура як код.
- Безперервне постачання.
- Зворотній зв'язок.
- Архітектура в DevOps, DevOps для CTO.
- SRE практики.
- Навчання та управління знаннями.
- Безпека, DevSecOps.
- DevOps-трансформація.
Call for Papers: які доповіді ми шукаємо
Потенційну аудиторію конференції ми умовно поділили на п'ять груп: інженери, розробники, спеціалісти з безпеки, тимліди та CTO. Кожна група має свою мотивацію прийти на конференцію. І якщо подивитися на DevOps з цих позицій, можна зрозуміти, як сфокусувати свою тему і де розставити акценти.
Для інженерів, які займаються створенням інфраструктурної платформи, важливо розібратися в існуючих трендах, зрозуміти, які технології зараз найпросунутіші. Їм буде цікаво ознайомитись із реальним досвідом використання цих технологій та обмінятися думками. Інженер із задоволенням вислухає доповідь із розбором якоїсь хардкорної аварії, ми в свою чергу таку доповідь постараємось підібрати та відшліфувати.
для розробників важливо розібратися з таким поняттям, як хмарний рідний додаток. Тобто як треба розробляти софт, щоб він працював у хмарах та різних інфраструктурах. Розробнику необхідно постійно отримувати зворотний зв'язок від програмного забезпечення. Тут ми хочемо почути кейси про те, як компанії вибудовують цей процес, як потрібно моніторити працездатність програмного забезпечення та як влаштований весь процес постачання.
Фахівцям у галузі кібербезпеки важливо розуміти, як налаштувати процес забезпечення безпеки таким чином, щоб він не стопорив процеси розробки та змін усередині компанії. Цікавими будуть і теми щодо вимог, які DevOps пред'являє до таких фахівців.
Тімліди хочуть знатияк влаштований процес continuous delivery в інших компаніях. Яким шляхом компанії до цього йшли, як вишиковувалися процеси розробки, забезпечення якості всередині DevOps. Cloud native тимлід теж цікавий. А ще — питання про взаємодію всередині команди та між командами розробників та інженерів.
Для CTO найголовніше — розібратися, як усі ці процеси поєднати та підлаштувати під бізнес-потрібні. Він піклується про те, щоб програма була надійною і для бізнесу, і для клієнта. І тут треба розуміти, які технології під якісь бізнес-завдання працюватимуть, як вибудувати процес цілком і т.д. CTO відповідає за бюджетування. Наприклад, він повинен розуміти скільки потрібно витратити грошей на перенавчання фахівців, щоб вони могли працювати в DevOps.
Якщо у вас є, що сказати з цих приводів, не мовчіть, . Крайній термін щодо Call for Papers - 20 серпня. Чим раніше заявитеся, тим більше часу буде на доопрацювання доповіді та підготовку до виступу. Так що не затягуйте.
Ну, а якщо потреби виступати публічно у вас немає, просто та приходьте 30 вересня та 1 жовтня спілкуватися з колегами. Обіцяємо, буде цікаво та надихаюче.
Як ми бачимо DevOps
Щоб точно розуміти, що ми вкладаємо в поняття DevOps, рекомендую прочитати (або перечитати) мою доповідь». Гуляючи хвилями ринку, я спостерігав, як трансформується уявлення про DevOps в різних за величиною компаніях: від невеликого стартапу до транснаціональних компаній. Доповідь побудована на серії питань, відповідаючи на них, можна зрозуміти, чи рухається ваша компанія до DevOps, чи десь є проблеми.
DevOps - це складна система, в ній мають бути:
- Цифровий продукт.
- Бізнес-модулі, які цей цифровий продукт розвивають.
- Продуктові команди, які пишуть код.
- Практики Continuous Delivery.
- Платформи як обслуговування.
- Інфраструктура як сервіс.
- Інфраструктура як код.
- Окремі практики підтримки надійності, зашиті всередині DevOps.
- Практика зворотний зв'язок, яка описує все це.
Наприкінці доповіді є схема, яка дає уявлення про DevOps-систему у компанії. Вона дозволить побачити, які процеси у вашій компанії вже налагоджені, а які тільки доведеться вибудовувати.
Відео доповіді можна переглянути .
А зараз буде бонус: кількох відео з РІТ++ 2019, які стосуються найбільш загальних питань DevOps-трансформації.
Інфраструктура компанії як продукт
Артем Науменко керує DevOps-командою у Skyeng та піклується про розвиток інфраструктури своєї компанії. Він розповів, як інфраструктура впливає на бізнес-процеси в SkyEng: як рахувати для неї ROI, які метрики варто вибрати для підрахунку і як працювати над їх поліпшенням.
На шляху до мікросервісів
Компанія Nixys займається підтримкою навантажених web-проектів та розподілених систем. Її технічний директор Борис Єршов розповів, як перевести на сучасні рейки програмні продукти, розробка яких розпочалася 5 років тому (або навіть більше).
Як правило, такі проекти — це особливий світ, де є такі темні та стародавні куточки інфраструктури, що про них не знають інженери, що нині діють. А вибрані колись підходи до архітектури та розробки застаріли та не можуть забезпечити бізнесу колишній темп розвитку та випуску нових версій. У результаті кожен реліз продукту перетворюється на неймовірну пригоду, де постійно щось відвалюється, причому в найнесподіванішому місці.
Керівники таких проектів неминуче стикаються із необхідністю трансформації всіх технологічних процесів. У своїй доповіді Борис розповів:
- як вибрати відповідну для проекту архітектуру та упорядкувати інфраструктуру;
- які інструменти використовувати та які підводні камені зустрічаються на шляху до трансформації;
- що робити далі.
Автоматизація релізів або як доставити швидко та без болю
Олександр Коротков - провідний розробник системи CI/CD в ЦИАН. Він розповів про інструменти автоматизації, які дозволили підвищити якість та скоротити час доставки коду у продакшн у 5 разів. Але таких результатів неможливо було б досягти лише однією автоматизацією, тому Олександр звернув увагу і на зміни у процесах розробки.
Як аварії допомагають навчатись?
Олексій Церпников уже 5 років займається впровадженням DevOps та інфраструктурою в СКБ Контур. За три роки у його компанії сталося приблизно 1000 факапів різного ступеня епічності. Серед них, наприклад, 36% викликано викочуванням неякісного релізу в продакшн, а 14% — роботами з обслуговування заліза в дата-центрі.
Отримувати таку точну інформацію про аварії дозволяє архів звітів (постмортеми), які інженери компанії ведуть кілька років поспіль. Постмортем пише черговий інженер, який першим відреагував на сигнал про аварію і почав все лагодити. Навіщо мучити інженерів, які ночами борються з факапами, написанням звітів? Ці дані дозволяють побачити картину і рухати інфраструктурну розробку в правильному напрямку.
У своєму виступі Олексій поділився, як написати справді корисний постмортем та як запровадити практику таких звітів у великій компанії. Якщо любите історії про те, як хтось облажався, перегляньте відео виступи.
Ми розуміємо, що ваше бачення DevOps може не співпадати з нашими уявленнями. Цікаво буде дізнатися, як ви бачите DevOps-трансформацію. Поділіться у коментарях своїм досвідом та баченням цієї теми.
Які доповіді ми вже прийняли до програми?
Цього тижня Програмний комітет ухвалив 4 доповіді: про безпеку, інфраструктуру та SRE-практики.
Мабуть, найболючіша тема DevOps-трансформації: як зробити так, щоб хлопці з відділу інформаційної безпеки не порушили вже збудовані зв'язки між розробкою, експлуатацією та адмініструванням. Деякі компанії обходяться і без відділу ІБ. Як у такому разі забезпечити інформаційну безпеку? Про це Мона Архіпова з sudo.su. З її доповіді ми дізнаємось:
- що і від кого слід захищати;
- які рутинні процеси безпеки;
- як перетинаються процеси ІТ та ІБ;
- що таке CIS CSC та як це впровадити;
- як і за якими показниками проводити регулярні перевірки ІБ.
Наступна доповідь стосується розвитку інфраструктури як коду. Зменшити кількість ручної рутини і не перетворити весь проект на хаос, чи можливо це? На це питання Максим Кострикін з Ixtens. У його компанії використовують Terraform для роботи з AWS інфраструктурою. Інструмент зручний, але питання в тому, як при його використанні уникнути появи величезної брили коду. Обслуговування такої спадщини з кожним роком коштуватиме все дорожче та дорожче.
Максим покаже, як працюють патерни розміщення коду, націлені на спрощення автоматизації та розвитку.
Ще один про інфраструктуру почуємо від Володимира Рябова з Playkey. Тут мова піде про інфраструктурну платформу, і ми дізнаємося:
- як зрозуміти, чи ефективно використовується обсяг сховища;
- як кілька сотень користувачів можуть отримати по 10 ТБ контенту, якщо використовуються лише 20 ТБ сховища;
- як стиснути дані в 5 разів та надавати їх користувачам у real-time;
- як нальоту синхронізувати дані між кількома дата-центрами;
- як унеможливити будь-який вплив користувачів один на одного при послідовному використанні однієї віртуальної машини.
Секрет цієї магії – у технології ZFS для FreeBSD та її свіжому форці ZFS на Linux. Володимир поділиться кейс від Playkey.
Матвій Кукуй з Amixr.IO готовий на прикладах із життя , що таке SRE та як воно допомагає будувати надійні системи. Amixr.IO пропускає інциденти клієнтів через свій бекенд, десятки чергових команд у всьому світі вже розібрали 150 тисяч випадків. На конференції Матвій поділиться статистикою та інсайтами, які його компанія накопичила, вирішуючи проблеми клієнтів та аналізуючи факапи.
Ще раз закликаю не скупитися і поділитися своїм досвідом DevOps-самурая. Подавайте на доповідь, і у нас з вами буде 2,5 місяці, щоб підготувати чудовий виступ. Якщо хочете бути слухачем, на розсилку з оновленнями програми і всерйоз замисліться про бронювання квитків, оскільки ближче до дат конференції вони подорожчають.
Джерело: habr.com