Привіт, я Валеріо, інженер-програміст, засновник & CTO at Inspector.
У цій статті я хотів би поділитися з вами своїм досвідом про те, чому розробники програмного забезпечення завжди повинні віддавати перевагу інструментам моніторингу, керованим кодом, а не керованим інфраструктурою.
Розуміння їхніх різних підходів може допомогти вам краще організувати свою команду, залишатися гнучким і швидким під час доставки та швидко виявляти проблеми, перш ніж ваші клієнти про них дізнаються.
Як технічний директор продукту моніторингу виконання коду Я маю можливість щотижня обговорювати цю тему з компаніями будь-якого розміру.Через помилки програмного забезпечення та простої я був свідком суперечок між командами, розгніваних клієнтів, скасованих контрактів, судових позовів та багатьох інших катастроф.
У більшості випадків це було просто оскільки команда розробників програмного забезпечення не була в належному стані для виконання своєї роботи.
У цій статті ви знайдете мій реальний життєвий досвід, який ви можете використати, щоб полегшити життя ваших розробників і уникнути втрати клієнтів і грошей через несподівані технічні проблеми у ваших програмах.
Чому моніторинг важливий
Багато розробників часто відчувають потребу контролювати свої програми, коли вони вперше починають працювати над середнім/великим проектом.Причина проста: коли програмне забезпечення стає складним або обслуговує дуже цінних клієнтів, помилки програмного забезпечення стають дорогими; подвійно, коли ваші клієнти знаходять їх! Клієнти можуть оцінити вас як ненадійних і шукати альтернативи.
Моніторинг — це спосіб для розробників уникнути несподіваних інцидентів і якомога довше утримувати задоволених клієнтів, що означає стабільний дохід з часом.
Моніторинг, керований інфраструктурою інструменти
Найвідоміші платформи моніторингу, такі як DataDog, Dynatrace, NewRelic, AppDynamics та інші, вимагають інсталяції та налаштування на рівні сервера або на ІТ-інфраструктурі загалом, але багато розробників не люблять з цим мати справу, а замість цього вони люблять залишатися зосереджено на кодуванні.
Інструменти, згадані вище, вимагають значної допомоги та навчання або навіть спеціалізованої групи інженерів (знайомих із серверами та інфраструктурою) для конфігурації та обслуговування, і, як правило, є надто складними та дорогими для малих/середніх команд, яким потрібно зосереджуватися лише на розробка додатків.
Робота з інфраструктурою є проблемою для багатьох розробників з двох причин:
1) Перевантаження роботою
Керування ІТ-операціями — це професія сама по собі . Це вимагає багато вертикальних навичок щодо серверних середовищ і включає складні технології (наприклад, Kubernetes).
Для базових потреб розробники, як правило, покладаються на зовнішні інструменти для автоматизації надання серверів, як-от панелі хмарного хостингу, платформи PaaS тощо, щоб зменшити це занепокоєння.
Але в середніх великих організаціях або при розширенні масштабів компанії може знадобитися спеціальна команда для догляду за інфраструктурою, що дозволить розробникам вільно витрачати час на роботу над кодом програми та впровадженням нових функцій.
2) Все, що налаштовано на рівні сервера, як правило, знаходиться поза контролем розробників < p>Незалежно від того, використовуєте ви інструменти автоматизації інфраструктури чи навіть маєте зовнішні команди, які піклуються про це, усе, що налаштовано на рівні сервера, виходить із життєвого циклу розробки програмного забезпечення, і розробники, як правило, втрачають свою автономію проти інших команд.Кожна команда у вашій компанії має власні потреби в моніторингу (Kubernetes, кібербезпека, мережі та інфраструктура, конфіденційність таВідповідність, застосування тощо). Те, що працює в одному сценарії, може бути вузьким місцем в іншому.
Нещодавно під час телефонної конференції з керівництвом однієї з найбільших комунальних компаній у Європі (Terna S.P.A.) Я побачив керівників команди розробки програмного забезпечення та групи операцій з інфраструктурою, які зустрілися вперше за роки роботи в компанії.
Оскільки обмін інструментами між різними командами було нелегко, замість того, щоб залежати від операційної групи для будь-якої конфігурації чи налаштування, розробники програмного забезпечення продовжували покладатися на журнали для моніторингу своїх програм.
Примушення до співпраці різних команд із різними цілями над одним інструментом може призвести до плутанини, постійного обміну електронною поштою між командами для коригування конфігурацій або налаштувань, і зрештою розробникам програмного забезпечення майже завжди залишається найгірше, оскільки вони не контролюють усе, що є встановлені всередині інфраструктури.
Якщо розробники не в належних умовах для виконання своєї роботи, вони витрачатимуть години чи дні на вирішення будь-якої проблеми.
Це чудовий приклад для кращого розуміння недоліків, які керовані інфраструктурою інструменти моніторингу можуть створити для розробників програмного забезпечення.
Інструмент моніторингу, керований кодом
< brНатомість керовані кодом інструменти моніторингу надають вам бібліотеку програмного забезпечення, яку можна встановити та використовувати, як і будь-які інші залежності програми (пакет композитора для програм PHP, модуль npm для nodejs тощо).Ідея керованого кодом інструменту моніторингу полягає у створенні середовища моніторингу, спеціально розробленого для розробників програмного забезпечення, уникаючи будь-якої конфігурації сервера чи інфраструктури, з якою багато розробників ненавидять мати справу.
Ця технічна відмінність (покладатися на бібліотеку додатків замість агента на рівні сервера) має багато наслідків для здатності розробників програмного забезпечення швидко виявляти помилки та вузькі місця в програмах, перш ніж вони призведуть до простою.
Завдяки інструменту, який можна встановити, вільно налаштовувати та налаштовувати, не залежаючи від будь-якої зовнішньої команди, розробники зможуть швидше виявляти та вирішувати проблеми в програмах:
Одна з найважливіших речей, за яку платять клієнти, — це «не мати проблем». Переконатися, що команда розробників програмного забезпечення може працювати швидко й незалежно, має вирішальне значення для того, щоб мати:
- With no interaction with other teams;
- Without endless tickets or email exchanges that are bounced on multiple levels inside the company;
- Without delays for your customers.
Для кількох місяців я поділився нашою ідеєю щодо Inspector як інструменту моніторингу, керованого кодом, виступаючи на заходах італійських спільнот PHP і обговорюючи з іншими технічним директором.На цій сторінці я зібрав відгуки розробників, які використовують Inspector у своїй щоденній роботі: https://www.inspector.dev/testimonials
- Less bug reports;
- Faster bug fix;
- More happy customers.
Не вірте моїм словам, спробуйте безкоштовно
Щоб дозволити всім зацікавленим спробуйте це нове рішення, ми пропонуємо абсолютно безкоштовний рівень до 30 000 транзакцій на місяць. Це не обмежене випробування.Ви та ваша команда можете ознайомитися з Inspector, не переслідуючи терміни.
Сподіваюся, вам сподобається працювати з Inspector.
Ми також створили реферальне посилання для цієї публікації.Використовуючи це посилання, ви отримаєте 50 000 додаткових трансакцій щомісяця як винагороду за читання LaravelNews - Зареєструйте свій обліковий запис - тому ви почнете свій обліковий запис із 80 000 щомісячних транзакцій, включених безкоштовно.
Або відвідайте наш веб-сайт, щоб дізнатися більше: https://інспектор.dev/laravel/
