Здравствуйте, меня зовут Валерио, инженер-программист, основатель & CTO в Inspector.
В этой статье я хотел бы поделиться с вами своим опытом о том, почему разработчики программного обеспечения всегда должны отдавать предпочтение средствам мониторинга, управляемым кодом, а не инфраструктуре.
Понимание их различных подходов может помочь вам лучше организовать свою команду, оставаться гибкими и быстрыми во время доставки, а также быстро выявлять проблемы до того, как о них узнают ваши клиенты.
Как технический директор продукта для мониторинга выполнения кода У меня есть возможность каждую неделю обсуждать эту тему с компаниями любого размера.Из-за программных ошибок и простоев я был непосредственным свидетелем споров между командами, недовольных клиентов, расторжений контрактов, судебных исков и многих других бедствий.
В большинстве случаев это было просто потому что команда разработчиков программного обеспечения была не в том состоянии, чтобы выполнять свою работу.
В этой статье вы найдете мой реальный жизненный опыт, который вы можете использовать, чтобы облегчить жизнь своим разработчикам и не потерять клиентов и деньги из-за непредвиденных технических проблем в ваших приложениях.
Почему важен мониторинг
Многие разработчики часто чувствуют необходимость мониторинга своих приложений, когда они впервые начинают работать над средним или большим проектом.
р>
Причина проста: когда программное обеспечение становится сложным или обслуживает очень ценных клиентов, программные ошибки становятся дорогими; вдвойне, когда ваши клиенты находят их! Клиенты могут оценить вас как ненадежного и поискать альтернативы.
Мониторинг позволяет разработчикам избегать неожиданных инцидентов и как можно дольше удерживать довольных клиентов, что означает стабильный доход с течением времени.
Мониторинг на основе инфраструктуры инструменты
Самые известные платформы мониторинга, такие как DataDog, Dynatrace, NewRelic, AppDynamics и другие, требуют установки и настройки на уровне сервера или ИТ-инфраструктуры в целом, но многие разработчики ненавидят с этим иметь дело, а вместо этого любят оставаться сосредоточен на программировании.
Упомянутые выше инструменты требуют большой помощи и обучения или даже специальной инженерной группы (знакомой с серверами и инфраструктурой) для настройки и обслуживания, и, как правило, слишком сложны и дороги для небольших/средних команд, которым нужно сосредоточиться только на разработка приложений.
Многих разработчиков беспокоит работа с инфраструктурой по двум причинам:
1) Перегруженность работой
Управление ИТ-операциями — это само по себе профессия . Это требует большого количества вертикальных навыков работы с серверными средами и включает сложные технологии (например, Kubernetes).
Для решения основных задач разработчики, как правило, полагаются на внешние инструменты для автоматизации подготовки серверов, такие как панели облачного хостинга, платформы PaaS и т. п., чтобы уменьшить эту проблему.
Но в организациях среднего размера или при расширении компании может потребоваться отдельная команда, которая будет заботиться об инфраструктуре, чтобы разработчики могли свободно тратить свое время на работу над кодом приложения и внедрение новых функций.
2) Все, что настроено на уровне сервера, как правило, не контролируется разработчиками
< р>Независимо от того, используете ли вы инструменты автоматизации инфраструктуры или даже привлекаете к этому сторонние команды, все, что настроено на уровне сервера, выходит за рамки жизненного цикла разработки программного обеспечения, и разработчики, как правило, теряют свою автономию по сравнению с другими командами.У каждой команды в вашей компании есть свои потребности в мониторинге (Kubernetes, кибербезопасность, сеть и инфраструктура, конфиденциальность и безопасность).Соответствие, применение и т.д.). То, что работает в одном сценарии, может оказаться узким местом в другом.
Недавно во время телефонной конференции с руководством одной из крупнейших коммунальных компаний Европы (Терна С.П.А..) Я впервые за много лет работы в компании встретил руководителей группы разработки программного обеспечения и группы эксплуатации инфраструктуры.
Потому что инструменты использовались разными командами. было непросто, вместо того, чтобы полагаться на оперативную группу для любой конфигурации или настройки, разработчики программного обеспечения продолжали полагаться на журналы для мониторинга своих приложений.
Принуждение к сотрудничеству разных команд с разными целями над одним и тем же инструментом может привести к путанице, постоянному обмену электронной почтой между командами для корректировки конфигураций или внесения изменений, и, в конце концов, разработчикам программного обеспечения почти всегда приходится хуже всего, потому что они не контролируют все, что есть. установлен внутри инфраструктуры.
Если разработчики не находятся в подходящих условиях для выполнения своей работы, они будут тратить часы или дни на решение любой проблемы.
Это прекрасный пример того, как лучше понимание недостатков, которые управляемые инфраструктурой инструменты мониторинга могут создавать для разработчиков программного обеспечения.
Инструмент мониторинга, управляемый кодом
< бр>Вместо этого инструменты мониторинга на основе кода предоставляют вам программную библиотеку, которую вы можете установить и использовать, как любые другие зависимости приложения (пакет композитора для приложений 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.
Одна из самых важных вещей, за которую клиенты платят, — это «отсутствие проблем». Убедиться, что команда разработчиков ПО может работать быстро и независимо, очень важно:
- Less bug reports;
- Faster bug fix;
- More happy customers.
Для некоторых месяцев я поделился нашей идеей об Inspector как инструменте мониторинга, управляемом кодом, выступая с докладами на мероприятиях итальянских сообществ PHP и обсуждая с другими техническими директорами.На этой странице я собрал отзывы разработчиков, использующих Inspector в своей повседневной работе: https://www.spawn.dev/testimonials
Не верьте моим словам, попробуйте бесплатно
Чтобы каждый желающий мог попробуйте это новое решение, мы предлагаем полностью бесплатный уровень, до 30 000 транзакций в месяц. Это не ограниченная пробная версия.Вы и ваша команда сможете ознакомиться с Inspector без каких-либо ограничений в сроках.
Надеюсь, вам понравится работать с Inspector.
Мы также создали реферальную ссылку для этого конкретного сообщения.Используя эту ссылку, вы получите 50 000 дополнительных ежемесячных транзакций в качестве награды за чтение LaravelNews. вы начнете свою учетную запись с 80 000 ежемесячных транзакций, включенных бесплатно.
Или посетите наш веб-сайт для получения более подробной информации: https://инспектор.разработчик/ларавель/
