Почему программная инженерия не так проста
Я не собираюсь лгать; у программистов довольно хорошая жизнь. Мы можем прийти в офис около 10 утра и все равно уйти около 17 часов. Нам редко приходится работать по выходным. При необходимости мы можем работать из дома. Мы получаем неограниченное количество закусок и бесплатную еду на обед, и мы приветствуем личный отпуск. В большинстве случаев это комфортная жизнь, но для меня работа может стать довольно напряженной и хаотичной.
Люди редко общаются по вызову с разработчиками программного обеспечения. Для большинства технических инженеров работа по вызову - довольно легкая нагрузка. Его может даже не быть, особенно для интерфейсных инженеров. Для бэкэнд-инженеров работа по вызову может стать тяжелой. Люди могут постоянно пинговать вас в Slack о проблемах, с которыми они сталкиваются. Вы можете проснуться в 3 часа ночи по выходным, чтобы решить техническую проблему. Недосыпание и шумная рабочая неделя могут быть частой темой для дежурства.
Моя команда
Я работаю в бэкэнд-команде, которая занимается распределенными системами обмена сообщениями, и эти системы служат основой продукта компании. Если наши службы перестают отвечать на запросы, продукт перестанет работать и, следовательно, потеряет доход. Поскольку наши услуги относятся к Уровню 1, для поддержания работоспособности наших систем требуется дежурный вызов.
Сотни приложений используют наши системы обмена сообщениями, и из-за большого объема использования все неожиданно ломается. У моей команды один из самых высоких показателей по количеству проблем в компании. За одну неделю моя команда может получить более 150 вопросов.
В течение года я дежурил около 12 раз, и каждая дежурная смена длится от 3 до 4 дней. В течение этих 3 или 4 дней я должен быть готов исправить проблемы, даже если сейчас 3 часа ночи в субботу. Быть по вызову означает постоянно приковывать наручники к телефону и ноутбуку. Критический инцидент неизбежен, и я никогда не знаю, когда он произойдет. Вот что пугает по вызову!
Критические проблемы во время разговора
Во время дежурства я сталкиваюсь с многочисленными типами проблем, но обычно возникают следующие проблемы:
- недоступность машины
- отставание в чтении данных
- место для хранения заполняется
- задержка публикации данных
Если машина недоступна, приложения не смогут считывать с нее данные и обрабатывать их для последующих служб. Этот инцидент может повлиять на работу приложения.
Задержка в использовании данных влияет на пользователей. Пользователи могут столкнуться с этой задержкой при загрузке контента. Представьте, что вы постоянно ждете более 5 минут, пока не появятся изображения. Такой пользовательский опыт может спровоцировать падение роста количества пользователей и, как следствие, выручку.
Чтобы решить эти проблемы, мне нужно открыть бесчисленное количество вкладок в моем Google Chrome и проанализировать данные с нескольких панелей мониторинга, чтобы получить полное представление о том, что происходит. Например, один график, на который мне нравится смотреть, - это входящий трафик с течением времени. Если я одновременно вижу внезапный всплеск трафика и внезапное падение успешности наших сервисов, я обращаюсь к команде, которая владеет этими данными, и просю их снизить трафик.
Без этих панелей мониторинга невозможно определить, как решить проблему. Наличие хорошо обслуживаемой системы мониторинга позволяет вашим сервисам быть надежными и стабильными. Если ваши сервисы не могут гарантировать эти характеристики, группы не будут использовать ваши сервисы.
Причины для страниц
Существует бесчисленное множество причин для появления множества страниц. Некоторые:
- плохие развертывания, в которых есть ошибка в выпуске
- запланированные отключения в конкретном центре обработки данных
- неожиданный рост клиентского трафика
- операционная ошибка
- шумные будильники
Некоторые проблемы возникают из-за отсутствия связи. Например, если команда увеличивает свой трафик, они должны сообщить нам заранее, чтобы мы могли внести какие-либо изменения в емкость, если это необходимо. В противном случае может произойти повышенная задержка чтения или потребителя, а пространство памяти может быстро заполниться.
Операционная ошибка может возникнуть из-за отсутствия документации на модуле Runbook. Модули Runbook описывают, какие команды следует запускать для выполнения определенной задачи, например, для слива или перезапуска компьютера. Однако не все модули Runbook идеальны. Они могут содержать устаревшую информацию. Определенная информация может даже отсутствовать. В этом случае инженер может запустить неверную команду, даже не осознавая этого.
Важно соответствующим образом обновлять модуль Runbook при появлении нового типа операции или нового инструментария. Обновление модулей Runbook должно быть упреждающим, а не реактивным.
Шаги к устойчивой дежурности
Моя команда недавно сосредоточилась на том, чтобы сделать наши будильники менее шумными. Это влечет за собой следующее:
- точная настройка порогов срабатывания сигнализации
- определение того, какие показатели нужно предупреждать, а какие можно игнорировать
- определение того, является ли метрика, о которой нужно предупреждать, высокой или низкой критичностью
Еще одна попытка сделать вызов по вызову более терпимым - отложить сигнал тревоги, когда происходит операция или развертывание, и сообщить об этом команде. В результате эта инженерная практика вынуждает инженера, выполняющего операцию, нести ответственность за эту услугу. Если во время этой операции все же возникает проблема, это ответственность инженера. Бремя дежурства снимается.
Преимущества по вызову
Хотя дежурство по вызову - это не весело, из этого можно многому научиться. Дежурный заставляет вас взаимодействовать со службами, с которыми вы не знакомы. Были случаи, когда мне приходилось копаться в кодовой базе сервиса. Я не являюсь экспертом в этой конкретной услуге, но могу участвовать в ее обсуждениях. Мне больше не нужно запутаться в том, о чем говорят другие инженеры!
Еще одно преимущество - вы быстрее решаете проблемы. Поскольку проблемы чувствительны ко времени, вы должны решать их быстро, иначе проблема перейдет к вышестоящему руководству. Вы быстрее узнаете, как отлаживать приложение. Вы научитесь правильно читать трассировку стека. Это важные навыки, которые нужно развить, чтобы стать опытным инженером.
Последние мысли
Программная инженерия - это не просто работа над кодом для внедрения новых функций. Для инженеров full-stack и back-end это также включает в себя мониторинг работоспособности ваших сервисов и принятие мер для поддержания этого работоспособности, что является непростой задачей.
Так что в следующий раз, если кто-то скажет, что разработчикам ПО легко, попросите его или ее встать на ваше место и действовать по вызову. Посмотрите, как долго продержится этот человек.
Ресурсы
Я провожу семинары по резюме / собеседованию с клиентами, претендующими на работу в области разработки программного обеспечения. Я работал с более чем 50 клиентами, и они получили предложения о работе в таких компаниях, как DoorDash, Square и 1Password.
Если вам нужна помощь с составлением резюме или подготовки к собеседованию, напишите мне на мой рабочий адрес электронной почты [email protected].
Йен - разработчик программного обеспечения в Twitter. Он работает в команде обмена сообщениями, поддерживая и улучшая системы pubsub. Он работал с многочисленными клиентами над повышением их технических навыков для работы с более чем 400 клиентскими сессиями.
