По мере своего карьерного роста я все чаще и чаще испытываю чувство дежавю. Во время личной или деловой встречи моему собеседнику достаточно упомянуть какой-то малозначительный факт — и я сразу же вспоминаю о событии, которое произошло со мной несколько лет (или даже «работ») назад. Чаще всего это касается неверно принятых мною решений, последствия которых пришлось расхлебывать долгие месяцы. Такие флешбеки настолько сильны, что я едва сдерживаюсь, чтобы не закричать человеку в лицо: «Ни в коем случае не делай X!». Почему сдерживаюсь? Всё просто: моих коллег не было в том месте и в то время и они попросту не поймут, каких ужасов я натерпелся в подобной же ситуации.
Именно поэтому я решил написать о худших ошибках, допущенных мною за годы работы. Возможно, эта статья сможет уберечь вас от неприятностей. Не переживайте: свои собственные ошибки вы всегда совершить успеете, на них я не покушаюсь. Но рассказ о моих заключениях наверняка пойдет вам на пользу.
Не торопитесь переносить приложения из ЦОДа в облако
Ох уж эти облачные сервисы, в последние годы никуда от них не скроешься. Шучу, конечно. Я и сам большой поклонник облаков. Тем не менее, зачастую огульная миграция в облако приложений, написанных для физической инфраструктуры, оборачивается проблемами.
Мне довелось поучаствовать в «переезде» трех крупномасштабных сервисов, изначально нацеленных на физические ресурсы. И каждый раз я сталкивался с подводными камнями, которые не покрывала ни одна официальная документация.
По мере написания и тестирования приложений у разработчиков формируется представление о том, как оно будет вести себя в продуктивной среде. Сюда относится то, как работают серверы, какую производительность показывает приложение на конкретном «железе», насколько надежна сеть и как велики задержки. Всё это приводит к тому, что приложения, особенно старые, после переноса в новую инфраструктуру начинают вести себя очень странно. Всплывают новые, неожиданные ошибки, и вы буквально вынуждены на месте решать их самыми причудливыми путями.
Вскоре оказывается, что ошибки и ограничения, с которыми вы столкнулись в новой среде, практически нивелируют ценность миграции. Что-то переносится с ошибками, что-то нельзя переносить вовсе — и вот вы уже оказались между Сциллой и Харибдой. С одной стороны — дата-центр, который приходится продолжать поддерживать. С другой — новая облачная среда.
Вместо этого...
Не переносите просто так — портируйте приложение в облачную среду. Пусть разработчики получат доступ к новым ресурсам, как следует их изучат, внесут в приложение доработки и определят, насколько целесообразна миграция. Обязательно запланируйте даунтайм на 4-8 часов, в течение которых приложение будет простаивать. И не пытайтесь экономить на времени простоя. Делайте всё спокойно, уверенно и с расстановкой.
Конечно же, самый лучший вариант — изначально разрабатывать приложение с прицелом на конечную среду. Но в ряде случаев это совершенно не применимый сценарий.
Не пишите собственную систему управления секретами
Честно говоря, я не знаю, почему до сих пор я раз за разом сталкиваюсь с подобной ситуацией. Компаниям очень нравится делать собственные системы управления секретами. Я лично стал жертвой подобной идеи, подумав: «Хм, ну разве тут могут возникнуть сложности?».
Я то ли встал не с той ноги, то ли сошел с ума — в тот злополучный день я решил, что управление секретами будет происходить через PostgrREST. Я написал утилиту, которая генерировала и отправляла приложениям JWT (JSON Web Token) на основе ряда критериев. Таким образом, думал я, приложения будут иметь доступ к своим секретам совершенно безопасным образом.
В защиту PostgrREST я могу сказать, что он достойно справился со своей частью функциональности. Проблема в том, что управление секретами в реальности немного сложнее, чем кажется на первый взгляд. Взять хотя бы кеширование: как избежать обращения к службе по миллиону раз в час, при этом сохраняя концепцию «сервер —источник истины»? Мне удалось решить проблему через конфигурацию Nginx, но это заняло какое-то время.
А потом мне в лоб прилетели смачные грабли ротации: обновить версию легко, но секреты, как правило, не передаются на клиентскую сторону. Поэтому во время ротации существуют сразу два верных секрета. Звучит вполне очевидно и ожидаемо, но во время разработки я не предусмотрел этот нюанс. Опять же, сделать быстрый фикс труда не составило, но со временем обнаруживались все новые и новые проблемы. Я понял, что совершил огромную ошибку, взвалив на себя самостоятельную разработку системы.
Реальность такова, что управление секретами — это классический пример сервиса с высокими рисками и низкой отдачей. Задачи клиентов он не решает, руководителей не впечатляет, а для его разработки требуются уйма времени и набор специфических знаний. Мне пришлось переделать заново едва ли не все аспекты своей изначальной программы.
Вместо этого...
Просто используйте AWS Secrets Manager или Vault. Я лично предпочитаю Secrets Manager, но тут выбор за вами. Только, заклинаю, не пишите свои собственные системы. В их разработке слишком много нюансов и сложностей, а на выходе вы получите крайне сомнительные преимущества. Экономия средств минимальна, но именно из-за вашего излишнего усердия все приложения в один прекрасный день перестанут работать.
Не запускайте собственный кластер Kubernetes
Да-да, у вас достаточно технических знаний и навыков. Может быть, вы вообще фанат etcd и настройки множества сертификатов. Но вот вам коротенькое дерево решений на случай, если вы решите запустить собственный кластер k8s:
1. Моя компания находится в списке Fortune 100?
Да: запускайте кракена кластер смело!
Нет: не стоит этого делать.
Лучше пусть кто-нибудь другой запустит этот кластер, а вы будете пользоваться его преимуществами. Например, у AWS EKS есть масса потрясающих функций, от AWS SSO в вашем kubeconfig-файле до возможности использовать роли IAM внутри ServiceAccounts для доступа модулей к ресурсам AWS. Вдобавок ко всему, меньше чем за 1000 долларов в год AWS возьмет на себя административные функции.
Я до сих пор не понимаю, почему эта проблема не на слуху. Да, вы можете самостоятельно и притом успешно запустить собственный кластер k8s, но — зачем? В случае с AWS буквально десятки тысяч бета-тестеров вперед меня убеждаются, что обновления EKS работают. Куча инженеров заняты поддержкой продукта. Если я и так размещаю в AWS свою инфраструктуру, с какой стати разворачивать собственный кластер? Разве что для поддержания иллюзии того, что в будущем я не буду привязан к одному провайдеру. Но об этом мы поговорим чуть ниже.
Вместо этого…
Пусть провайдер облачных услуг занимается ваши кластером. А вы сосредоточьтесь на том, чтобы ваши собственные разработчики не испытывали сложностей или неудобств.
Не цельтесь сразу в нескольких облачных провайдеров
Эта тема волнует меня на самом личном уровне. Один крайне способный менеджер убедил меня в том, что наша компания должна иметь возможность в любое время сменить облачного провайдера.
Я попался на эту удочку и оказался в так называемой «команде преждевременных оптимизаторов».
Через некоторое время я решил провести аудит новых сервисов на предмет совместимости с несколькими облачными платформами. Вместо SDK от AWS мы использовали свои собственные, чтобы без проблем переключиться, если придется выбрать нового провайдера. С учетом того, что текущее облако нас устраивало, переехать или расшириться мы могли только в случае экспансивного роста бизнеса — чего в ближайшие годы явно не предвиделось.
Следующий пассаж я хотел бы адресовать в первую очередь провайдерам облачных услуг: не делайте вид, что клиенту на самом деле может потребоваться развернуть свои приложения в нескольких разных облаках. Экстренная надобность в этом может возникнуть только в том случае, если вы, провайдер, закроетесь одним днем. Все остальные сценарии миграции подразумевают, что у клиента найдется время на полноценную подготовку и переезд.
На деле вероятность того, что облачный провайдер проживет дольше, чем ваша компания, крайне высока. И в подавляющем большинстве случаев не стоит задумываться о переезде с первого дня в новом облаке.
Возвращаясь к моей истории — мы обросли кучей устаревших библиотек, поэтому наши разработчики лишь читали о замечательных новых функциях AWS, однако использовать их не могли. Ни один туториал с нашей прекрасной переносимой библиотекой не работал, разработчики злились, а до реальной миграции дело так и не дошло.
Вместо этого...
Если кто-то говорит, что вы не должны быть привязаны к единственному поставщику облачных услуг, ответьте прямо: этот поезд ушел в момент регистрации, я остаюсь тут. Как и в случае миграции из ЦОДа в облако, приложение, разработанное и протестированное на совместимость с конкретной инфраструктурой, может начать чудить в новом облаке.
С другой стороны, «максимальная мобильность» может выйти вам боком и ограничить возможности. Если вы оказались в ситуации, когда переход к новому провайдеру имеет финансовую подоплеку, выделите как минимум 3 месяца на тестирование и портирование каждого приложения. Получившийся ворох задач может запросто уничтожить все выгоды от миграции.
Облачные провайдеры — это как язык программирования. Нельзя просто так взять и переключиться с одного на другой. Поэтому всегда оценивайте риски и преимущества — и, самое главное, не мешайте клиентам пользоваться вашими сервисами, если всё и так корректно работает.
Не допускайте роста количества бессмысленных оповещений
Я уверен, что вы лично не раз сталкивались с подобной ситуацией: где-то в офисе установлен экран, подключенный к системе мониторинга. Периодически на нем загорается какое-то предупреждение, но никто не торопится с ним разбираться. Мол, «это мелочь, мы просто следим, чтобы такая ерунда не происходила слишком уж часто».
В конечном итоге, прямо как в сказке про мальчика, который слишком часто кричал «Волк!», произойдет действительно серьезный сбой — все из-за того, что дежурный инженер машинально проигнорирует важное оповещение из-за большого потока «мусорных».
Именно в такой ситуации я и оказался. Мне пришлось поддерживать систему, построенную моим предшественником, и я не дал себе труда переписать непонятные модули или разобраться, откуда приходят лишние оповещения. Реальный сбой, который мы не заметили, не заставил себя долго ждать.
Вместо этого...
Не допускайте «замусоривания» системы предупреждениями о всякой ерунде и не стесняйтесь избавляться от чужих «хвостов» и ошибок. Если система присылает вам alert-email 600 раз на дню, она бесполезна.
Не пишите внутренние инструменты cli на Python
Коротенький и простой совет.
Никто не знает, как правильно устанавливать и упаковывать Python-приложения. Если вы пишете внутренний инструмент, он должен быть либо полностью переносимым, либо написанным на Go или Rust. Избавьте себя и пользователя от страданий с приложениями, которые не хотят корректно устанавливаться.
