Метка: ошибка

  • Sentry для отлова ошибок

    Sentry для отлова ошибок

    Пользователи жалуются, что на сайте возникает ошибка. У разработчика “всё работает”. В команде разработки никто ошибку не может воспроизвести ни на одном устройстве. Бывает, что в логах нет ничего, потому что ошибка произошла на фронте. Или записи не информативны. А пользователи продолжают жаловаться…

    Чтобы разбираться с этими случаями, в нашей веб-студии мы подключаем к проектам Sentry. Это мониторинг ошибок и производительности приложения. В отличие от обычных логов, Sentry показывает гораздо больше информации об ошибке:
    – новая ли это ошибка
    – сколько таких ошибок возникло за последние дни
    – весь стек вызова
    – чему были равны переменные окружения
    – какие библиотеки были подключены
    – какой браузер и устройство у пользователя
    – информацию о пользователе
    – содержимое запроса
    – что делал пользователь до ошибки
    – версию, релиз и коммит

    Это всё позволяет очень быстро найти реальную причину возникшей проблемы.

    Мы подключаем Sentry на фронт, это также просто, как установка обычного счётчика или npm-пакета. И подключаем отдельно на бэк — Sentry умеет интегрироваться с любым языком и фреймворком за счёт готовых SDK.

    Раньше мы пользовались SaaS-версией, но некоторое время назад всех РФ-пользователей попросили завершить обслуживание. Так что, я развернул бесплатную self-hosted версию на своей VDS. Система прожорливая, Docker Compose запускает три десятка контейнеров, поэтому требуется достаточно мощный сервер. Такой сервер у нас выходит на 4000 рублей в месяц, зато обслуживает десятки небольших проектов.

    Sentry — инструмент для быстрого поиска ошибок разработчиками. Не заменяет потоки логов и мониторинг инфраструктуры. Рекомендую всем, кому нужно ловить баги в продакшине.

  • Я чайник!

    Я чайник!

    В 1990 году первым устройством, управляемым через интернет, стал тостер. А 1 апреля 1998 года был предложен шуточный стандарт RFC 2324 для управления кофе-машинами через HTTP-протокол.
    Браузер шлёт запрос на веб-сервер, а веб-сервер сообщает браузеру о своём состоянии кодом из трёх цифр. Для тех случаев, когда запрос на варку кофе получает чайник, был выделен специальный код статуса веб-сервера 418 — Я чайник. Он должен сообщить, что сервер не сможет сварить кофе, но вместо этого сервер сообщает, что он простой чайник. Ответ фактически правильный, но пользователю не помогает — ну, чайник, а мне что делать-то?

    Мы должны видеть страницу сайта или страницу с ошибкой и понятными инструкциями. Коды со статусом веб-сервера предназначены для программистов, сисадминов и SEOшников. Кодов более 60, с некоторыми из них вы наверняка сталкивались.
    404 — Страница не найдена. Самый известный код ответа. День вебмастера отмечается каждый год 4.04. Эти страницы часто оформляют веб-дизайнеры.
    301 — Документ переехал. Чаще всего этот статус появляется в результате работы SEOшника. Пользователя моментально перенаправляет на другой адрес.
    500 — Внутренняя ошибка сервера. Программист залил код с ошибками.
    502 — Шлюз недоступен. Позовите сисадмина.
    503 — Сервис недоступен. Позовите сисадмина и программиста.

    Разработчики веб-серверов умеют хорошо писать серверный код, а про красивые и понятные сайты только слышали от знакомых. Поэтому сотни тысяч людей каждый день фрустрированы созерцанием 500ых ошибок в тупиках интернета.

    Однажды программисты научат серверы сообщать в случае ошибок, что этот сайт не сможет сварить вам кофе. Но это неточно.

  • Расфокус в растущем агентстве

    Расфокус в растущем агентстве

    Основная ошибка первых лет жизни моего агентства — большая матрица услуг.

    Как она разрастается. У тебя появляется клиент, с которым выстраиваются по-настоящему классные отношения и есть результат. Он приходит с идеей: «А давайте вы нам будете делать ещё одну услугу?» Агентству очень нужны заказы и новые клиенты даются с трудом. Очень соблазнительно взять дополнительные деньги у старого клиента. Но маленькому агентству так делать опасно.

    Это типичная ловушка.
    – Внимание основателя начинает сильно размываться.
    – В молодом агентстве ещё не всё отработано с оказанием основной услуги.
    – Услуги будут оказываться с разным качеством. Если вы налажаете с новой услугой — ухудшатся отношения со стабильным клиентом.
    – Чтобы сделать из новой услуги систему, нужен не один клиент, а поток. Где брать таких же клиентов вы ещё не понимаете.
    – Скорее всего, оказание услуги будет прибыльном только в уме. Мы не учитываем внимание основателя, управленческие часы, косвенные расходы и трудозатраты на решение проблем.
    – Настоящая прибыль пойдёт, когда на отстроенной услуге будет группа клиентов и несколько исполнителей. Это ещё не ваш случай.
    – В новое направление нужно осознанно закладывать инвестиции денег и времени.
    – Это внимание, время и деньги будет выгоднее вложить в улучшения по основному направлению.

    Отказываться от денег и заманчивых предложений очень сложно. Но не надо отказываться! Найдите партнёра, который специализируется только на этой услуге. Познакомьте его с вашим клиентом и посмотрите, как пройдёт это взаимодействие. Вдруг клиент откажется от этой услуги через три месяца? Стоило ли под него открывать направление?

    Куда разумнее не делить своё внимание, а получить партнёрскую комиссию и опыт партнёрства. Возможно, в скором будущем этот партнёр отдаст вам новых клиентов.

  • Лиды нужны слабым агентствам

    Лиды нужны слабым агентствам

    В профессиональных услугах производство ограничено по ёмкости — крутых людей так быстро и просто не клонировать по щелчку пальцев.
    Вы определились с услугой, делаете действительно классно, есть кейсы и довольные клиенты, у вас средняя цена, новые клиенты легко покупают.

    В таких условиях лиды вам будут нужны только первое время, чтобы запустить волну рекомендаций. Если у вас услуга рекуррентная, то вы быстро упрётесь в потолок по производству.

    Вопросы на размышление.
    – Если стоматолог делает очень хорошо и недорого, как легко к нему записаться на ближайшее время?
    – Стоматология давно на рынке, но ей очень нужны новые клиенты — что там не так? Плохо делают, задраны цены, ошибка в выборе места или проблемный руководитель?
    – Надо ли такую клинику брать в клиенты агентству?
    – Если ваше агентство круто делает услугу, а клиенты довольны, то почему клиенты вас не рекомендуют?

    Говорят, что сарафан невозможно прогнозировать и масштабировать. Но если его совсем нет, то компания что-то делает не так и расти органически не выйдет.

    Итак, агентству нужны лиды:
    – если агентство оказывает услугу средне или плохо и/или клиенты недовольны. NPS < 7 - если агентство выводит новую услугу и нужны первые случайные жертвы - если агентство решает масштабировать свою услугу и набрало новый персонал - если агентство делает редкую услугу с маленьким сроком жизни клиента Агентство даёт прямую рекламу и остро нуждается в клиентах? Скорее всего, заказ будут делать слабые сотрудники, сделают плохо, а агентство скоро закроется. Хотите поговорить об этом с потенциальным подрядчиком?

  • Как код попадает на сервер 2025 edition

    Как код попадает на сервер 2025 edition

    Как раньше: открыл удалённую папку на сервере по FTP, скопировал туда свои файлы — сайт работает.

    К каким проблемам это приводило:
    – Два разработчика скачали один и тот же файл, внесли правки и по очереди загрузили их на сервер. Изменения первого разработчика стёрты вторым.
    – Разработчики работают прямо на сервере. Человеческий фактор неизбежно приводит к ошибкам.

    Как это выглядит у нас сейчас:
    – Разработчик копирует код из Git-репозитория (git clone/git pull)
    – Создаёт свою ветку, в ней изменения хранятся отдельно (git checkout -b)
    – Вносит изменения в свой экземпляр (git commit)
    – Отправляет изменения обратно в репозиторий (git push)
    – Создаёт запрос на добавление своих изменений в общий код (Merge Request)
    – Робот 🤖 на новом поддомене разворачивает тестовую копию сайта с изменениями (Review Apps) и запускает тестирование
    – Менеджер, Тестировщик и другие разработчики смотрят и щупают изменения
    – Разработчик дорабатывает код, тестовый сайт автомагически обновляется
    – После принятия запроса на слияние (Merge Request) все новые изменения автоматически выкатываются на промежуточный сервер
    – С промежуточного сервера время от времени все обновления попадают на основной сервер (тоже через Merge Request)

    В итоге менеджеры могут одновременно отслеживать прогресс разных задач на тестовых доменах и давать обратную связь.
    Дополнительные бонусы: исключаем риск утечки данных (152-ФЗ) и рукожопства на сервере (🤖).