Вы не узнаете этого из учебника
Прошел почти год с тех пор, как я покинул Amazon, и с тех пор я многому научился и понял, работая в Twitter.
1. Состояние службы
Разработка программного обеспечения не ограничивается созданием новых функций для использования клиентами; это также обеспечивает работоспособность и работоспособность существующих служб. Сервисы никогда не должны падать в производительности. Это важно для поддержания доверия ваших клиентов. Если ваши существующие службы не могут обеспечить такое же SLA (соглашение об уровне обслуживания), тогда почему клиенты будут использовать ваши услуги?
Есть множество способов поддерживать сервисы:
- По вызову
- Мониторинг
- Системы автоматизации
- Операционная гигиена
Oncall вносит наибольший вклад в поддержание работоспособности ваших услуг. Если служба выходит из строя в реальном времени, вызов по вызову может смягчить это как можно скорее. В противном случае, чем дольше инцидент остается неразрешенным, тем выше последствия. Например, влияние на конечного пользователя может заключаться в невозможности подключить новых пользователей, что приводит к потере доходов. Наивысший приоритет - никогда не подвергать продукт опасности, чтобы пользователи перестали его использовать.
Внутренние клиенты могут пинговать вызовы через коммуникационную платформу, такую как Slack, когда их услуги или рабочие места работают плохо. В большинстве случаев входящие вызовы отслеживаются системой мониторинга. Система мониторинга позволяет инженерам отслеживать производительность своих сервисов с помощью ключевых показателей, таких как коэффициент успешности, задержка чтения / записи, трафик, объем памяти и т.д. services и, таким образом, может быстрее устранять проблемы.
В этих системах мониторинга можно установить порог для ключевых показателей, и когда этот порог будет превышен, вызов будет отправлен на пейджинг. Однако эти пороги могут быть палками о двух концах. Если пороговые значения не установлены тщательно (т.е. установлены слишком низкие или слишком высокие), вызовы могут быть переполнены страницами. Порог должен быть установлен на значение, которое будет нарушено только тогда и только тогда, когда у службы возникнут проблемы. Точно так же инженер не должен переусердствовать и устанавливать порог для каждой метрики. Вам необходимо предупреждать о показателях, которые являются действенными и могут иметь разрушительные последствия, если их не решить быстро.
Жизнеспособным решением для облегчения звонков и улучшения работоспособности ваших услуг является автоматизация. Если определенная проблема постоянно повторяется и может быть решена без ручного вмешательства, можно использовать автоматизацию. Системы автоматизации могут иметь большое влияние, но в то же время могут дать нежелательные результаты, если не будут реализованы меры безопасности. Например, при перезапуске экземпляров службы с отслеживанием состояния важно не перезапускать их все одновременно.
Системы автоматизации можно даже интегрировать с системами мониторинга. Системы мониторинга могут запускать автоматизацию при достижении порогового значения для определенной метрики.
Очень важно соблюдать высокую производственную гигиену, чтобы не допустить возникновения проблем и инцидентов при ручных операциях. Один из способов решить эту проблему - иметь хорошо документированный модуль Runbook, в котором перечислены подробные шаги для каждой ручной операции. Кроме того, другой член команды может проверить процедуру операции оператора, особенно если известно, что операция вызывает проблемы.
50% программной инженерии поддерживает работоспособность сервисов. Это нетривиальная часть работы. Программная инженерия - это не просто написание кода.
2. Устойчивость Кодекса
Важно убедиться, что любой добавляемый код гибок к изменениям. Это особенно важно при изменении бизнес-требований.
I.) Используйте принцип DRY
DRY означает «Не повторяйся». Один и тот же фрагмент кода не следует повторять многократно. Если вы это видите, возможно, вам придется абстрагироваться от него, чтобы избежать избыточности. Если вам когда-нибудь понадобится изменить его логику, вам просто нужно изменить ее в одном месте.
II. Всегда проверяйте
Всегда пишите тестовые примеры для любых функций, которые вы пишете. Важно, чтобы любые добавляемые новые функции не нарушали существующее состояние системы. Тестирование может быть утомительным, но оно принесет огромные плоды.
III. Архитектура превыше всего
Если вы не учитываете архитектуру при написании кода, это будет иметь эффект снежного кома. При написании кода подумайте о том, как другие службы будут с ним взаимодействовать, насколько легко обновить его в будущем и как вы можете его протестировать. Код должен быть написан таким образом, чтобы, если нужно поменять одну логику, легко было вставить новую логику.
IV.) Используйте константы
Никогда ничего не кодируйте жестко. Вместо этого используйте константы. Таким образом, если значение когда-либо потребуется обновить в будущем, вам просто нужно изменить его один раз, а не несколько раз.
3. Проявите инициативу
Инженеры никогда не должны останавливаться на достигнутом. Они должны работать над тем, чтобы стать лидером в своей команде. Чтобы усилить свое влияние в команде, вы должны проявлять инициативу и быть готовыми браться за новые задачи, которые вам не нравятся. Признаком отличного инженера является то, что он или она может решить новую задачу с минимальной помощью. Я начал участвовать в большем количестве обзоров кода служб, с которыми я не знаком. Я заставил себя критиковать больше технических проектных документов в отношении крайних случаев или слабых мест. Я даже поговорил со своим менеджером, чтобы поручить мне участвовать в проектах, которые помогут мне усилить мои слабые стороны.
Стремление к новому - не единственное, что вам следует делать. Вам также необходимо заранее продумать, с какими проблемами столкнется ваша команда и как они будут решаться. Всегда думайте наперед и решайте ее как можно раньше, прежде чем она станет реальной проблемой. Проактивность - это навык, над которым я сейчас работаю. Надеюсь, работая над этими навыками и целями, я смогу достичь следующего уровня.
Я многому научился за последний год и надеюсь узнать еще больше в следующие несколько лет!
Ресурсы
Я провожу семинары по резюме / собеседованию с клиентами, претендующими на работу в области разработки программного обеспечения. Я работал с более чем 50 клиентами, и они получили предложения о работе в таких компаниях, как DoorDash, Square и 1Password.
Если вам нужна помощь с составлением резюме или подготовки к собеседованию, напишите мне на мой рабочий адрес электронной почты [email protected].
Йен - разработчик программного обеспечения в Twitter. Он работает в команде обмена сообщениями, поддерживая и улучшая системы pubsub. Он работал с многочисленными клиентами над повышением их технических навыков для работы с более чем 400 клиентскими сессиями.
