Не забудьте поширити ❤️
Майже рік тому розробник Йен Хуан пішов з Amazon в Twitter. Ось чого його встигла навчити соцмережа за цей час.
1. Підтримувати сервіси в робочому стані
Розробка – це не тільки створення нових функцій, але і підтримка існуючих. Сервіси ніколи не повинні відставати в продуктивності. Це потрібно, щоб зберегти довіру клієнтів. Якщо існуючі сервіси не можуть забезпечувати той же SLA (угода про рівень обслуговування), то навіщо клієнтам їх використовувати?
Існує безліч способів підтримувати сервіси в робочому стані.
- Oncall
Ця система має на увазі, що хтось із розробників постійно знаходиться на зв’язку і готовий прийняти заявку від клієнта. Це основний спосіб підтримувати роботу сервісів. Якщо станеться збій, черговий зможе оперативно з ним впоратися. Чим довше інцидент залишається невирішеним, тим серйознішими будуть наслідки. Наприклад, не вийде залучити нових користувачів, що призведе до втрати грошей. Дуже важливо ніколи не піддавати продукт такій небезпеці.
- Моніторинг
Внутрішні клієнти можуть відправляти заявки через комунікаційну платформу, наприклад, Slack. Велику частину часу заявки черговому надходять від системи моніторингу. Вона дозволяє розробникам відстежувати продуктивність сервісів за допомогою таких показників, як коефіцієнт успішності, затримка читання/запису, трафік, обсяг пам’яті тощо. В результаті черговий може отримувати повну інформацію про те, що відбувається в сервісах, і швидше розв’язувати проблеми.
У системах моніторингу можна встановити поріг для ключових показників, і, коли вони будуть перевищені, черговий отримає повідомлення. Але це – палиця з двома кінцями. Якщо недбало визначити поріг (тобто встановити занадто низькі або надто високі показники), заявок буде занадто багато. Тому потрібно вибрати такий поріг, який буде вказувати на реальні проблеми сервісу. Крім того, не варто старатися і встановлювати поріг для кожної метрики. Сповіщення повинні приходити про найважливіші показники, які можуть мати руйнівні наслідки, якщо їх швидко не повернути в норму.
- Автоматизація
Це відповідне рішення для oncall і підтримки роботи сервісів. Якщо певна проблема постійно повторюється і її можна вирішити без ручного втручання, автоматизація для цього підійде. Вона може бути дуже корисною, але водночас здатна привести до небажаних результатів. Наприклад, важливо не перезапускати всі екземпляри сервісу з відстеженням стану одночасно. Системи автоматизації навіть можна інтегрувати з системами моніторингу. Другі здатні запускати автоматизацію щоразу, коли для певної метрики досягається граничне значення.
- Операційна гігієна
Дуже важливо мати високу операційну гігієну, щоб ручні операції не спровокувати проблеми. Один зі способів розв’язати це завдання – написати інструкцію, в якій будуть детально описані кроки для виконання кожної ручної операції. Крім того, інший член команди може перевірити роботу оператора, особливо якщо відомо, що ця операція викликає проблеми.
50% завдань розробника – підтримка сервісів в робочому стані. І це завдання не можна назвати рядовим. Розробка – це не просто написання коду.
Чотири книги, які повинен прочитати кожен розробник
2. Писати надійний код
Важливо переконатися, що будь-який введений код гнучко реагує на зміни. Це особливо важливо, коли змінюються вимоги бізнесу.
- Принцип DRY
DRY означає Do not Repeat Yourself – “не повторювати себе”. Один і той же фрагмент коду не повинен повторюватися кілька разів. Якщо це так, то вам, можливо, доведеться оптимізувати його, щоб уникнути надмірності. Якщо знадобиться змінити логіку коду, коригування потрібно буде внести тільки в одному місці.
- Тести
Придумуйте тестові випадки для всіх функцій, які ви додаєте. Важливо, щоб нововведення не порушували існуючу систему. Тестування може бути утомливим, але воно дуже корисне.
- Архітектура
Якщо при написанні коду не враховувати архітектуру, проблеми будуть збиратися як сніжний ком. Подумайте, як інші сервіси стануть взаємодіяти з вашим, наскільки легко його вийде оновити в майбутньому і як його можна протестувати. Код повинен бути написаний таким чином, щоб зміні логіки нічого не перешкоджало.
- Постійні значення
Не йдіть на ризик – замість цього використовуйте константи. Якщо значення будь-коли буде потрібно оновити, редагування доведеться внести тільки один раз.
3. Проявляти ініціативу
Розробнику шкідливо стагнувати – йому варто прагнути до лідерства в команді. Щоб збільшити впливовість, проявляйте ініціативу і готуйтеся взяти на себе нові завдання, які вам не подобаються. Хороший розробник може впоратися з новим завданням з мінімальною допомогою. Я почав більше аналізувати код сервісів, з якими я не був знайомий. Я змусив себе частіше критикувати технічні проєктні документи, що стосуються крайніх випадків або вразливостей. Я навіть попросив керівника, щоб він призначив мене на проєкти, які допоможуть мені розвинути свої слабкі сторони.
Знадобиться не тільки пробувати себе в новій області, але ще й продумувати, з якими труднощами може зіткнутися ваша команда і як з ними впоратися. Завжди міркуйте про майбутнє і розв’язуйте проблеми на етапі виникнення – до того, як вони розростуться. Проактивність – навичка, над якою я зараз працюю. Сподіваюся, з її допомогою я зможу вийти на наступний рівень.
Ми у соцмережах: