Три проф совета от разраба Twitter

Практически годом ранее разраб Йен Хуан ушел из Amazon в Twitter. Вот чему его успела обучить соцсеть за этот период времени.

Три проф совета от разраба Twitter

Лена Лиханова

1. Поддерживать сервисы в рабочем состоянии

Разработка — это не только лишь создание новейших функций, да и поддержка имеющихся. Сервисы никогда не должны отставать в производительности. Это необходимо, чтоб сохранить доверие клиентов. Если имеющиеся сервисы не могут обеспечивать этот же SLA (соглашение о уровне обслуживания), то для чего клиентам их употреблять?

Существует огромное количество методов поддерживать сервисы в рабочем состоянии.

Oncall

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

Мониторинг

Внутренние клиенты могут отправлять заявки через коммуникационную платформу, к примеру, Slack. Огромную часть времени заявки дежурному поступают от системы мониторинга. Она дозволяет разрабам выслеживать производительность сервисов при помощи таковых характеристик, как коэффициент удачливости, задержка чтения/записи, трафик, размер памяти и так дальше. В итоге дежурный может получать полную информацию о том, что происходит в сервисах, и резвее решать препядствия.
В системах мониторинга можно установить порог для главных характеристик, и, когда они будут превышены, дежурный получит извещение. Но это — палка о 2-ух концах. Если небережно найти порог (другими словами установить очень низкие либо очень высочайшие характеристики), заявок будет очень много. Потому необходимо избрать таковой порог, который будет указывать на настоящие препядствия сервиса. Не считая того, не стоит усердствовать и устанавливать порог для каждой метрики. Оповещения должны приходить о важных показателях, которые могут иметь разрушительные последствия, если их стремительно не возвратить в норму.

Автоматизация

Это подходящее решение для oncall и поддержания работы сервисов. Если определенная неувязка повсевременно повторяется и ее можно решить без ручного вмешательства, автоматизация для этого подойдет. Она быть может весьма полезна, но в то же время способна привести к ненужным результатам. К примеру, принципиально не перезапускать все экземпляры сервиса с отслеживанием состояния сразу. Системы автоматизации даже можно интегрировать с системами мониторинга. 2-ые способны запускать автоматизацию каждый раз, когда для определенной метрики достигается пороговое значение.

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

50% задач разрабочика — поддержание сервисов в рабочем состоянии. И эту задачку недозволено именовать неиндивидуальной. Разработка — это не попросту написание кода.

2. Писать надежный код

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

Принцип DRY

DRY значит Don’t Repeat Yourself — «не повторяйтесь». Один и этот же фрагмент кода не должен повторяться пару раз. Если это так, то для вас, может быть, придется улучшить его, чтоб избежать избыточности. Если пригодится поменять логику кода, корректировки необходимо будет внести лишь в одном месте.

Испытания

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

Архитектура

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

Неизменные значения

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

3. Проявлять инициативу

Разрабу вредоносно стагнировать — ему стоит стремиться к лидерству в команде. Чтоб прирастить влиятельность, проявляйте инициативу и готовьтесь взять на себя новейшие задачки, которые для вас не нравятся. Неплохой разраб может совладать с новейшей задачей с малой помощью. Я начал больше рассматривать код сервисов, с которыми я не был знаком. Я принудил себя почаще критиковать технические проектные документы, касающиеся последних случаев либо уязвимостей. Я даже попросил управляющего, чтоб он провозгласил меня на проекты, которые посодействуют мне развить свои слабенькие стороны.

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

Источник.

Фото: Unsplash 

Источник: rb.ru