У доповіді буде розказано про деякі DevOps практики, але з погляду розробника. Зазвичай усі інженери, які приходять у DevOps, вже мають за плечима кілька років досвіду адміністрування. Але це не означає, що розробнику тут немає місця. Найчастіше розробники зайняті тим, що виправляють "черговий терміново-критичний баг дня", і вони не мають часу навіть одним вічком поглянути на DevOps сферу. У розумінні автора DevOps — це, по-перше, здоровий глузд. По-друге, це можливість бути більш ефективним. Якщо ви розробник, маєте здоровий глузд і хочете бути більш ефективним як командний гравець — доповідь для вас.
Уявлюся, я цілком припускаю, що в залі є люди, які мене не знають. Звати мене Антон Бойко, я є Microsoft Azure MVP. Що таке MVP? Це Model-View-Presenter. Model-View-Presenter – це я.
Крім того, я зараз обіймаю посаду solution architect у компанії Ciklum. І буквально недавно купив собі такий гарний домен, і в мене оновився мій email, який я зазвичай показую на презентаціях. Можете писати мені на: me [собака] byokoant.pro. Мені на пошту можна писати запитання. Я зазвичай на них відповідаю. Єдине, я не хотів би отримувати питання на пошту, які стосуються двох тем: це політика та релігія. Про все інше можете писати мені на пошту. Мине якийсь час, я відповім.
Пару слів про себе:
- Вже 10 років я у цій сфері.
- Я працював у Microsoft.
- Я батько-засновник української Azure-спільноти, яку ми заснували десь у 2014-му році. І досі воно у нас є та розвивається.
- Я також батько засновник Azure-конференції, яка проходить в Україні.
- Також я допомагаю організувати Global Azure Bootcamp у Києві.
- Як я вже сказав, я – Microsoft Azure MVP.
- Я часто виступаю на конференціях. Я дуже люблю виступати на конференціях. За минулий рік мені вдалося виступити близько 40 разів. Якщо пробігатимете повз Україну, Білорусь, Польщу, Болгарію, Швецію, Данію, Нідерланди, Іспанію або плюс-мінус іншої країни в Європі, то цілком можливо, що, заходячи на конференцію, яка має тему хмар у себе в потоці, ви можете побачити мене у списку доповідачів.
- А ще я – фанат Star Trek.
Давайте трохи поговоримо про Agenda. Agenda у нас дуже проста:
- Ми поговоримо про DevOps. Поговоримо чому це важливо. Раніше DevOps – це було ключове слово, яке ви писали в резюме та отримували одразу +500 доларів до зарплати. Зараз потрібно писати, наприклад, blockchain у резюме, щоб отримати +500 доларів до зарплати.
- А потім, коли ми трошки розберемося, що це являє собою, ми поговоримо про те, які є DevOps-практики. Але не так у контексті DevOps в цілому, а про ті DevOps-практики, які могли б бути цікаві розробникам. Я розповім, чому вони могли б бути вам цікавими. Розкажу, навіщо взагалі це робити і як це може допомогти вам відчувати менше болю.
Традиційна картинка, яку показують багато хто. Це те, що відбувається у багатьох проектах. Це коли ми маємо відділи розробки та operations, які підтримують наш софт. І ці відділи між собою не спілкуються.
Можливо, якщо ви не настільки яскраво змогли відчути саме на відділах DevOps та operations, ви можете провести аналогію з відділами Dev та QA. Є люди, які розробляють софт і є QA, які погані з погляду розробників. Наприклад, я коммічу до репозиторію свій прекрасний код, а там сидить якийсь негідник, який мені цей код повертає і каже, що ваш код поганий.
Це все відбувається через те, що люди між собою не спілкуються. І вони через якусь стіну непорозуміння перекидають один одному якісь пакети, якийсь додаток і намагаються щось з ними робити.
Саме зруйнувати цю стіну і покликана DevOps-культура, тобто. змусити людей між собою спілкуватися і хоча б розуміти, чим взагалі займаються різні люди у проекті та чому їхня робота важлива.
І коли ми говоримо про DevOps, то хтось скаже, що DevOps – це коли в проекті є continuous integration; хтось скаже, що DevOps – якщо в проекті реалізована практика "інфраструктура як код"; хтось скаже, що перший крок до DevOps – це feature branching, feature flags.
По суті це все по-своєму правда. Але це лише кінцеві практики, які у нас є. Перед тим, як переходити до цих практик, я пропоную подивитися на цей слайд, який показує три етапи впровадження Dev-Ops методології у вашому проекті, у вашій компанії.
Цей слайд має ще другу неофіційну назву. Ви можете пошукати в інтернеті, що таке 3 мушкетери DevOps. Цілком можливо, ви знайдете цю статтю. Чому 3 мушкетери? Внизу написано: люди, процеси та продукти, тобто. PPP – Портос, Портос та Портос. Ось вам 3 мушкетери DevOps. Ця стаття описує більш розгорнуто, чому це важливо і що це під собою несе.
Коли ви починаєте впроваджувати DevOps-культуру, дуже важливо, щоб вона впроваджувалась у наступному порядку.
Спочатку вам потрібно говорити з людьми. І вам потрібно пояснити людям, що це таке, і як вони зможуть отримати від цього якісь переваги.
Конференція називається DotNet Fest. І як мені сказали організатори, що сюди в нас в основному було запрошено аудиторію розробників, тому я сподіваюся, що більшість людей у залі займаються розробкою.
Ми поговоримо про людей, поговоримо, що розробники хочуть робити щодня. Чого вони хочуть найбільше? Вони хочуть писати якийсь новий код, використовувати новомодні фреймворки, пиляти нові фічі. Чого розробники хочуть найменше? Фіксувати старі баги. Я сподіваюся, ви зі мною погодитеся. Це те, що хочуть розробники. Вони хочуть писати нові фічі, вони хочуть фіксувати баги.
Кількість багів, які виготовляє той чи інший розробник, залежить від того, наскільки у нього прямі руки і наскільки вони ростуть із плечей, а не з кишень на попі. Проте, коли проект у нас великий, іноді буває так, що за всім встежити неможливо, тому нам було б непогано використовувати якісь підходи, які допоможуть писати більш стабільний та якісніший код.
Що найбільше хочеться QA? Не знаю, чи є вони у залі. Мені важко говорити, що хочеться QA, бо я ніколи не був ним. І не в образу хлопцям буде сказано, що ніколи, сподіваюся, не буду. Але не з тієї причини, що вважаю їхню роботу безглуздою і марною, а тому що я не вважаю себе людиною, яка змогла б цю роботу виконувати якісно, тому я навіть не намагатимуся це робити. Але з того, що я розумію, QA найбільше не подобається виходити вранці на роботу, ганяти постійно якісь regression tests, наступати на ті самі баги, які вони зарепортували розробникам 3 спринту тому і говорити: «Коли ж ви, мосьє Д 'Артаньяне, пофіксуйте цей баг». А мосьє Д'Артаньян йому відповідає: «Так-так, я вже його пофіксував». І як це буває, що один баг пофіксував, 5 дорогою зробив.
Люди, які займаються підтримкою цього рішення на production, хочуть, щоб це рішення працювало без багів, щоб їм не доводилося перепіднімати сервер щоп'ятниці, коли всі нормальні люди йдуть у бар. Розробники у п'ятницю задеплоїлися, адміни сидять до суботи, намагаючись цей деплой підняти, полагодити.
І коли ви поясните людям, що вони націлені на вирішення тих самих завдань, ви можете переходити до формалізації процесів. Це дуже важливо. Чому? Бо коли ми говоримо «формалізація», то вам важливо описати, як ваші процеси відбуваються хоча б десь на серветці. Вам потрібно зрозуміти, що якщо ви, наприклад, робите деплою на QA-оточення або на production-оточення, то це завжди відбувається ось у такому порядку, ось на таких етапах ми запускаємо, припустимо, автоматичні unit-тести, UI-тести. Після деплою перевіряємо, наскільки деплой пройшов добре чи погано. Але у вас вже є чіткий список дій, які повинні повторюватися щоразу, коли ви робите деплою на production.
І тільки коли у вас процеси формалізовані, ви приступаєте до вибору продуктів, які допоможуть вам ці процеси автоматизувати.
На жаль, я дуже часто бачу, що це відбувається у зворотному порядку. Як тільки хтось чує слово "DevOps", відразу пропонує поставити Jenkins, тому що вважає, що як тільки вони поставлять Jenkins, у них буде DevOps. Вони поставили Jenkins, почитали статті How to на сайті Jenkins, спробували процеси запхати в ці How to статті, а потім прийшли до людей і нахилили людей, сказавши, що книжка каже, що потрібно робити ось так, тому робимо ось так.
Не те, що Jenkins є поганий інструмент. Я в жодному разі не хочу це сказати. Але це лише один із продуктів. І те, який продукт ви використовуватимете, має бути ваше останнє рішення, а в жодному разі не перше. У вас продукт не повинен драйвувати використання саме культури та підходів. Це дуже важливо зрозуміти, саме тому я так довго кручусь на цьому слайді і так довго все це пояснюю.
Давайте поговоримо про DevOps-практики загалом. Які вони є? Чим вони відрізняються? Як їх поміряти? Чому вони важливі?
Перша практика, про яку ви могли чути, називається Continuous Integration. Можливо, хтось має на проекті Continuous Integration (CI).
Найбільша проблема в тому, що найчастіше, коли я питаю людину: «Чи є у вас CI на проекті?» і він каже: «Так», то коли я питаю, що він робить, він мені описує абсолютно весь процес автоматизації. Це не зовсім так.
Насправді практика CI лише спрямована на те, що код, який пишуть різні люди, інтегрується в якусь єдину базу коду. От і все.
Разом із CI дорогою йдуть зазвичай ще різні практики — такі, як Continuous Deployment, Release Management, але про це ми поговоримо потім.
Сам CI нам каже, що різні люди пишуть код, і цей код повинен інтегруватися безперервно в єдину базу коду.
Що це нам дає і чому важливо? Якщо у нас DotNet, то це добре, це компілювання мови, ми можемо скомпілювати наш додаток. Якщо воно компілюється, то це вже добрий знак. Це ще нічого не означає, але це вже перший добрий знак, що ми хоча б можемо скомпілюватися.
Потім ми можемо запустити якісь тести, що також є окремою практикою. Тести всі зелені – це вже другий добрий знак. Але знову ж таки це ще нічого не означає.
Але навіщо вам це робити? Всі практики, про які я розповідатиму сьогодні, під собою несуть приблизно однаковий value, тобто приблизно однакові переваги і міряються теж приблизно однаково.
Перше – це дозволяє прискорити доставку. За рахунок чого це дозволяє прискорити доставку? Коли в нас заходять якісь нові зміни до нашої кодової бази, ми можемо відразу спробувати з цим кодом щось зробити. Ми не чекаємо, поки у нас прийде четвер, тому що в четвер ми релізимо це на QA Environment, ми робимо це прямо тут і прямо тут.
Я розповім вам одну сумну історію з мого життя. Це було давно, коли я ще був молодим і красивим. Зараз я вже молодий, вродливий і розумний, і скромний. Якийсь час тому я був у одному проекті. У нас була велика команда з 30 розробників. І у нас був великий-великий Ентерпрайз-проект, який розвивався близько 10 років. І в нас були різні гілки. У репозиторії ми мали гілку, у якій гуляли розробники. І була гілка, яка відображала версію коду, який є на production.
Гілка виробництва від гілки, яка була доступна для розробників, відставала на 3 місяці. Що це означає? Це означає, що як тільки в мене десь якийсь баг пішов на production з вини розробників, тому що вони його допустили, і з вини QA, тому що вони його переглянули, це означає, що якщо мені прилітає завдання на hotfix для production'а, то я мушу відкотити свої кодові зміни на 3 місяці тому. Я маю згадати, що у мене було 3 місяці тому і спробувати це там пофіксувати.
Якщо у вас ще не було такого досвіду, то можете спробувати це зробити на вашому домашньому проекті. Головне, не спробуйте на комерційному. Напишіть пару рядків коду, забудьте про них на півроку, а потім поверніться і спробуйте швидко пояснити, про що ці коди рядки і як можна їх виправити або оптимізувати. Це дуже цікавий досвід.
Якщо у нас є практика Безперервної інтеграції, це дозволяє нам прямо тут і прямо зараз, як тільки я написав свій код, перевірити його рядом автоматичних інструментів. Нехай це не дасть мені повну картину, але це прибере хоча б частину ризиків. І якщо там буде якась потенційна бага, я про це дізнаюся прямо зараз, тобто буквально за кілька хвилин. Мені не потрібно буде відкочуватися на 3 місяці тому. Мені потрібно буде відкотитися лише на 2 хвилини тому. За 2 хвилини хороша кавоварка навіть кави не встигне зварити, тому це досить класно.
Це несе у собі цінність, що це можна повторювати щоразу кожному проекті, тобто. не лише на одному, на якому ви це налаштували. Можна повторювати як саму практику, так і сам CI повторюватиметься на кожну нову зміну, яку ви вносите в проект. Це дозволяє оптимізувати ресурси, тому що ваша команда працює більш ефективно. У вас вже не буде ситуації, коли до вас прилітає баг із коду, з яким ви працювали 3 місяці тому. У вас уже не буде перемикання контексту, коли ви сидите і перші дві години намагаєтеся зрозуміти, що було тоді і в'їхати в суть контексту перед тим, як почнете щось виправляти.
Як можна поміряти успіх чи неуспіх цієї практики? Якщо отраппортувати великому босу, що ми впровадили на проекті CI, він чує бла-бла-бла. Впровадили, Ок, а навіщо це нам принесло, як ми це поміряємо, наскільки ми правильно чи неправильно впроваджуємо?
Перше, це те, що за рахунок CI ми можемо робити деплою частіше та частіше, і частіше саме з тієї причини, що у нас потенційно це стабільніший код. Так само у нас зменшується час на пошук помилки і зменшується час на виправлення цієї помилки саме з тієї причини, що ми отримуємо відповідь від системи прямо тут і зараз, що з нашим кодом не так.
Інша практика, яка у нас є, це практика автоматичного тестування, яка найчастіше йде з практикою CI. Вони йдуть пліч-о-пліч.
Що тут важливо розуміти? Важливо розуміти, що тести у нас різні. І кожний автоматичний тест націлений на вирішення своїх завдань. У нас є, припустимо, unit-тести, які дозволяють протестувати окремо якийсь модуль, тобто. як він працює у вакуумі. Це добре.
Також ми маємо інтеграційні тести, які дозволяють нам зрозуміти, як різні модулі інтегруються між собою. Це також добре.
У нас можуть бути UI automation тести, які дозволяють нам перевірити, наскільки робота з UI відповідає тим чи іншим вимогам, які виставив замовник і т.д.
Які саме тести ви запускаєте, це може впливати на періодичність їх запуску. Unit-тести зазвичай у нас пишуться короткими, невеликими. І їх можна запускати регулярно.
Якщо ми говоримо про UI automation тести, то добре, якщо у вас маленький проект. У вас UI automation тести можуть проходити за якийсь час. Але зазвичай UI automation тест - це річ, яка йде на великому проекті кілька годин. І це добре, якщо кілька годин. Єдине, на кожен build запускати їх сенс немає. Є сенс їх запускати вночі. І коли вранці всі прийшли на роботу: і тестувальники, і розробники, то вони одержали якийсь звіт, що ми вночі поганяли автотестом UI і такі результати отримали. І тут година роботи сервера, який перевірятиме на те, що ваш продукт відповідає якимось вимогам, буде набагато дешевше, ніж година роботи того ж QA-інженера, навіть якщо це Junior QA-інженер, який працює за їжу та за спасибі. Все одно година роботи машини буде дешевшою. Саме тому має сенс у це інвестувати.
Я маю ще один проект, на якому я працював. Ми мали двотижневі спринти на цьому проекті. Проект був великий, важливий для фінансового сектора, і помилки допустити було не можна. І за двотижневим спринтом, за циклом розробки далі йшов процес тестування, який займав ще 4 тижні. Спробуйте уявити масштаб трагедії. Два тижні ми пишемо код, потім ми робимо аля CodeFreeze, пакуємо це в нову версію програми, викочуємо тестувальникам. Тестувальники ще чотири тижні його тестують, тобто. доки вони його тестують, ми встигаємо ще дві версії їм підготувати. Це реально сумний випадок.
І ми їм сказали, що якщо ви хочете працювати продуктивніше, вам має сенс впроваджувати практику Автоматичного тестування, тому що це те, що у вас болить прямо тут і зараз.
Практика безперервного розгортання. Добре, ви зробили build. Це вже добре. У вас код скомпілювався. Тепер було б непогано цей build розгорнути на якомусь оточенні. Допустимо, на оточенні для розробників.
Чому це важливо? По-перше, ви можете подивитися, наскільки успішно у вас відбувається процес розгортання. Я зустрічав такі проекти, коли я запитую: «Як ви розгортаєте нову версію програми?», мені хлопці кажуть: «Ми її збираємо та пакуємо у zip-архів. Відправляємо адміну поштою. Адмін цей архів хитає, розгортає. І вся контора починає молитись, щоб сервер підхопить нову версію».
Почнемо із чогось простого. Наприклад, в архів забули покласти CSS або забули поміняти хештег на ім'я java-script файлу. І коли ми робимо запит до сервера, то браузер вважає, що це java-script файл у нього вже є і вирішує його не перекачувати. А там була стара версія, чогось не вистачало. Загалом проблем може бути багато. Тому практика Безперервного розгортання дозволяє вам як мінімум перевірити, що буде, якщо ви візьмете чистий еталонний образ і заллєте його на повністю чисте нове оточення. Ви можете подивитись, до чого це приведе.
З іншого боку, коли ви інтегруєте код між собою, тобто. між командою, це дозволяє вам також переглянути, як це виглядає на UI.
Одна з проблем, яка зустрічається, де використовується багато ванільного java-script, це те, що два розробники взяли та згарячи в об'єкті window оголосили змінну з одним ім'ям. І потім, як пощастить. Чий java-script файл витягнеться другим, той і перетрете зміни іншого. Це теж дуже цікаво. Ти заходиш: в однієї людини одне працює, в іншого – інше не працює. І «прекрасно», коли все це вилазить на production.
Наступна практика, яка у нас є, це практика Автоматичного відновлення, а саме відкату на попередню версію програми.
Чому це важливо для розробників? Є ще ті, хто пам'ятають далекі 90-ті, коли комп'ютери були великі, а програми маленькі. І шлях у веб-розробку лежав лише через php. Не те, що б php – це погана мова, хоч це й так.
Але проблема була в іншому. Коли ми деплоїли нову версію нашого php-сайту, ми як його деплоїли? Найчастіше ми відкривали Far Manager чи щось інше. І ці файли заливали на FTP. І ми раптом зрозуміли, що у нас якась маленька-маленька бага, наприклад, ми забули крапку з комою поставити чи забули поміняти пароль від бази, і там стоїть пароль від бази, яка на local хості. І вирішуємо швидко підключитися на FTP і відредагуємо файли прямо там. Оце просто вогонь! Це те, що було популярно у 90-х.
Але якщо ви не заглядали в календар, 90-ті були майже 30 років тому. Зараз уже все відбувається трохи інакше. І спробуйте уявити масштаб трагедії, коли вам кажуть: Ми задеплоїли на production, але там щось пішло не так. Ось тобі логін і пароль від FTP, підключайся на production і швиденько там виправи». Якщо ви Чак Норріс, то це спрацює. Якщо ні, то ви ризикуєте, що ви поправите одну багу, зробите ще 10. Саме тому ця практика відкату на минулу версію, дозволяє вам досягти багато чого.
Навіть якщо щось десь якось погане пролізло на prod, то це погано, але не смертельно. Ви можете відкотитись на попередню версію, яка у вас є. Назвіть це бекапом, якщо простіше в такій термінології сприймати. Ви можете відкотитись на цю попередню версію, і користувачі все одно зможуть працювати з вашим продуктом, а у вас з'явиться адекватний запас часу. Ви зможете спокійно, без поспіху, все це взяти та локально протестувати, пофіксувати, а потім уже залити нову версію. Це реально має сенс робити.
Тепер давайте спробуємо поєднати десь якось дві попередні практики разом. Ми отримаємо третю, яка називається Release Management.
Коли ми говоримо про Continuous Deployment у класичному його поданні, то ми говоримо, що ми повинні витягнути з репозиторію код із якоїсь гілки, скомпілювати та задеплоїти. Це добре, якщо ми маємо одне оточення. Якщо у нас оточення кілька, то це означає, що ми повинні щоразу витягувати код нехай навіть із того ж таки комміту. Ми щоразу його витягуватимемо, щоразу його билдитимемо і будемо деплоїти на нове оточення. По-перше, це час, тому що на будівництві проекту, якщо він у вас великий і прийшов з 90-х, то це може зайняти кілька годин.
Крім того, є інший смуток. Коли ви будете білдити нехай навіть на тій самій машині, ви будете білдити ті самі вихідники, у вас все одно немає гарантії, що ця машина знаходиться в тому ж стані, в якому вона була під час минулого білда.
Допустимо, хтось зайшов і оновив вам DotNet або, навпаки, хтось вирішив щось видалити. І потім у вас когнітивний дисонанс, що з цього комміту два тижні тому ми білдили білд і все було добре, а зараз начебто та сама машина, той самий коміт, той самий код, який ми намагаємося білдити, але не виходить. Ви довго з цим розбиратиметеся і не факт, що розберетеся. Принаймні нервів зіпсуйте собі дуже багато.
Тому практика Release Management пропонує впровадити додаткову абстракцію, яка називається сховищем артефактів або галереєю, або бібліотекою. Можна назвати як завгодно.
Основна ідея в тому, що, як тільки у нас з'являється там якийсь коміт, припустимо, у гілці, яку ми вже готові деплоїти на наші різні оточення, ми збираємо додатки з цього комміту і все, що нам потрібне для цього додатку, ми пакуємо в zip-архів і зберігаємо в якомусь надійному сховищі. І з цього сховища ми цей zip-архів можемо будь-якої миті дістати.
Потім ми беремо і автоматично розгортаємо його на dev-оточенні. Там ганяємо, і якщо все гаразд, то розвертаємо на stage. Якщо все добре, то розгортаємо на production той самий архів, одні й самі бінарники, скомпільовані рівно один раз.
Крім того, коли ми маємо ось таку галерею, це також допомагає нам адресувати ризики, які ми адресували на минулому слайді, коли ми говорили про rollback до попередньої версії. Якщо ви випадково задеплоїли щось не те, ви завжди можете з цієї галереї взяти будь-яку іншу попередню версію і так само роздеплоїти на ці оточення. Це дозволяє вам у разі якогось шухера легко відкотитись на попередню версію.
Є ще одна чудова практика. Всі ми з вами розуміємо, що коли ми відкочуємо наші додатки на попередню версію, це може означати, що інфраструктура нам потрібна також попередньої версії.
Коли ми говоримо про віртуальну інфраструктуру, багато хто думає, що це щось таке, що налаштовують адміни. І якщо вам потрібно, скажімо, отримати новий сервер, на якому ви хочете потестувати нову версію вашої програми, то ви повинні писати тикет адмінам або девопсам. Девопси братимуть на це 3 тижні. І через 3 тижні скажуть, що ми тобі встановили віртуалку, де одне ядро, два гігабайти оперативної пам'яті та Windows-сервер без DotNet. Ви кажете: "А я хотів DotNet". Вони: "Ок, приходь через 3 тижні".
Ідея в тому, що, використовуючи практику "Інфраструктура як код", ви можете ставитись до вашої віртуальної інфраструктури лише як до ще одного чергового ресурсу.
Можливо, якщо хтось із вас розробляє програми на DotNet, ви могли чути про таку бібліотеку, як Entity Framework. І, можливо, ви навіть чули, що Entity Framework – це один із підходів, який Microsoft активно пушить. Для роботи з базою даних це підхід, який називається Code First. Це коли ви в коді описуєте, як ви хочете, щоб виглядала ваша база даних. І потім ви розгортаєте програму. Воно підключається до бази, воно саме визначає, які таблиці є, яких таблиць немає, і все, що вам потрібно, створює.
Так само ви можете робити з вашою інфраструктурою. Немає жодної різниці між тим, чи потрібна вам для проекту база даних або потрібен для проекту Windows-сервер. Це лише ресурс. І ви можете автоматизувати створення цього ресурсу, ви можете автоматизувати налаштування цього ресурсу. Відповідно, щоразу, коли ви захочете протестувати якусь нову концепцію, якийсь новий підхід, вам не треба буде писати тикет девопсам, ви зможете взяти і просто розгорнути самі собі з уже готових шаблонів, із готових скриптів ізольовану інфраструктуру та провести там усі ваші експерименти. Можете видалити це, отримати якісь результати і потрапити про це далі.
Наступна практика, яка теж є і також важлива, але якою мало хто користується, це Application Performance Monitoring.
Про Application Performance Monitoring хотів сказати лише одну річ. Що найбільше важливо у цій практиці? Це те, що Application Performance Monitoring – це приблизно так само, як ремонт у квартирі. Це не фінальний стан, це процес. Вам потрібно проводити його регулярно.
По-хорошому було б добре Application Performance Monitoring проводити мало не на кожен build, хоча, як ви розумієте, далеко не завжди це можливо. Але щонайменше на кожен реліз його потрібно проводити.
Чому це важливо? Тому що якщо у вас раптом пішла просідання за продуктивністю, то вам потрібно чітко розуміти через що. Якщо у вас у команді, припустимо, двотижневі спринти, то ви хоча б раз на два тижні повинні розгортати ваш додаток на якийсь окремий сервер, де у вас чітко фіксований процесор, оперативна пам'ять, диски і т. д. І проганяєте ті самі тести продуктивності. Отримуєте результат. Дивіться, як воно змінилося від попереднього спринту.
І якщо ви дізнаєтеся про те, що просідання пішло різко кудись вниз, то це означатиме, що це було лише через зміни, які були протягом останніх двох тижнів. Це дозволить вам набагато швидше визначити та виправити цю проблему. І знову це ті ж приблизно метрики, якими можна поміряти, наскільки успішно це у вас вийшло.
Наступна практика, яка є, це практика Configuration Management. Дуже мало, хто ставиться до цього серйозно. Але, повірте мені, це справді дуже серйозна штука.
Нещодавно була кумедна історія. Прийшли до мене хлопці та кажуть: «Допоможи провести нам security audit нашої програми». Ми довго дивилися разом у код, вони мені розповідали про програму, малювали схеми. І плюс-мінус все було логічно, зрозуміло, безпечно, але було одне АЛЕ! Вони в source control лежали конфігураційні файли зокрема від production з IP бази даних, з логінами і паролями для підключення до цих баз даних і т.д.
І я кажу: «Хлопці, добре ви firewall-ом закрили своє production-оточення, але те, що у вас є логін і пароль від production-бази прямо в source control і будь-який розробник має можливість це прочитати, це вже величезний ризик безпеки. І яким би суперзахищеним ваша програма не була з погляду коду, якщо у вас це залишиться лежати в source control, то ніколи ніде ніякого аудиту ви не пройдете». Ось про що я й говорю.
Управління конфігурацією. На різному оточенні ми можемо мати різну конфігурацію. Наприклад, у нас можуть бути різні логіни та паролі для баз даних для QA, demo, production-оточення і т.д.
Налаштування цієї конфігурації також можна автоматизувати. Вона повинна завжди бути окремою від безпосередньої програми. Чому? Тому що програму ви збилдили один раз, і потім додатку все одно - підключаєтеся до SQL-серверу по такому IP або по такому IP, він повинен працювати однаково. Тому якщо раптом хтось із вас досі хардкодит connection string у коді, то запам'ятайте, що я вас знайду і покараю, якщо ви опинитеся зі мною на одному проекті. Це завжди виноситься в окрему конфігурацію, наприклад, web.config.
І ця конфігурація вже керується окремо, тобто це саме той момент, коли може прийти розробник та адмін, сісти в одній кімнаті. І розробник може сказати: «Дивися, ось бінарники мого додатка. Вони працюють. Додатку до роботи потрібна база даних. Ось поруч із бінарниками лежить файл. У цьому файлі це поле відповідає за логін, за пароль, це за IP. Деплой його куди завгодно». І адміну це просто та зрозуміло. Він може це деплоїти і справді куди завгодно, керуючи цією конфігурацією.
І остання практика, про яку хотів би сказати, це практика, яка дуже сильно ставиться до хмар. І максимальний ефект вона приносить, якщо ви працюєте у хмарі. Це автоматичне видалення вашого оточення.
Я знаю, що на цій конференції є кілька людей з тих команд, з якими я працюю. І з усіма командами, з якими я працюю, ми використовуємо цю практику.
Чому? Звичайно, було б класно, якби на кожного розробника була б віртуальна машина, яка працювала б 24/7. Але, можливо, вам це новина, можливо, ви не звертали увагу, але сам по собі розробник не працює 24/7. Розробник працює зазвичай 8 годин на день. Нехай він приходить на роботу рано, має великий обід, протягом якого він ходить до спортзалу. Нехай це 12 годин на день, коли розробник реально користується цими ресурсами. За нашим законодавством у нас у тижні є 5 із 7 днів, які вважаються робітниками.
Відповідно, у робочі дні ця машина повинна працювати не 24 години, а лише 12, а на вихідні ця машина працювати взагалі не повинна. Здається, все дуже просто, але що тут важливо сказати? Впроваджуючи ось цю просту практику за таким базовим розкладом, це дозволяє вам зменшити вартість утримання цих оточень на 70%, тобто ви ціну на ваші dev, QA, demo, environment ви взяли та поділили на 3.
Питання, що робити з рештою грошей? Наприклад, купити розробникам ReSharper, якщо ще не купили. Або влаштувати коктейльну вечірку. Якщо у вас раніше було одне оточення, на якому паслися і dev, і QA, і все, то тепер ви можете зробити 3 різних, які будуть ізольовані, і люди не заважатимуть один одному.
Що стосується слайду з постійним виміром продуктивності, як можна порівняти продуктивність, якщо у нас у проекті було 1 000 записів у базі даних, через два місяці їх мільйон? Як зрозуміти, чому і який сенс у вимірі продуктивності?
Це добре питання, тому що ви продуктивність повинні заміряти завжди на одних і тих же ресурсах. Т. е. ви викочуєте новий код, ви заміряєте продуктивність на новому коді. Наприклад, вам необхідно перевірити різні сценарії продуктивності, припустимо, ви хочете перевірити, як програма працює на легкому навантаженні, де 1 користувачів і розмір бази даних 000 гігабайтів. Ви заміряєте, отримали цифри. Далі беремо інший сценарій. Наприклад, 5 користувачів, розмір бази 5 терабайт. Здобули результати, запам'ятали.
Що тут важливе? Тут важливо те, що залежно від сценарію, від обсягу даних, кількості одночасних користувачів і т. д., ви можете упертися в ті чи інші ліміти. Наприклад, в ліміт мережної карти або в ліміт жорсткого диска, або в ліміт можливостей процесора. Ось що вам важливо зрозуміти. На різних сценаріях ви упираєтеся в ті чи інші ліміти. І треба розуміти цифри, коли ви в них упретеся.
Тут йдеться про вимір продуктивності на спеціальному тестовому оточенні? Т. е. це не production?
Так, це не production, це тестове оточення, яке завжди однакове, щоб ви могли порівняти його з попередніми вимірами.
Зрозумів спасибі!
Якщо питань немає, я гадаю, можемо закінчити. Дякую!
Джерело: habr.com