Я везде вижу инструменты администратора. Инструменты администратора, которые только один или два человека используют один раз в голубую луну, чтобы изменить какую-либо конфигурацию. Эти вещи почти всегда не нужны. Это пережитки давно минувших дней, когда релизы планировались за месяцы вперед. Давно пора поставить их на полку.

Ваш инструмент администратора впустую

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

Ловушка файла конфигурации

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

Как мы это делали

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

Стоимость отходов

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

  • работа — работа, связанная с созданием и обслуживанием конфигурации и/или инструмента администрирования, требует циклов разработки. Эти циклы лучше потратить на вещи, которые приносят пользу.
  • талант — люди, которым приходится работать над обыденными, не имеющими ценности вещами, такими как инструменты администратора, ненавидят это делать. У меня была стажировка в старших классах в государственном научно-исследовательском учреждении. Моя работа заключалась в мытье ведер для исследования кислотных дождей. Это были совершенно новые ведра прямо от производителя. Они были настолько чистыми, насколько это вообще возможно. Был процесс, которому я должен был следовать, чтобы вымыть ведра. Я не буду утомлять вас подробностями, просто знайте, что это было очень строго и подробно. Представьте, на что может быть похоже мытье нового чистого ведра. Вот каково это работать с вашим инструментом администратора.
  • обфускация — чем дальше этот материал отходит от соответствующего кода, который фактически выполняет работу, тем более запутанной становится функциональность приложения. Приложение сложнее для понимания. Есть риск, что люди упустят что-то, когда нужно будет внести изменения. Эти изменения займут больше времени, потому что есть больше движущихся частей. Вы уменьшаете сплоченность и одновременно увеличиваете связанность. Практика чистого кодирования должна делать обратное.
  • отслеживание изменений — отслеживаете ли вы, кто вносит изменения? Если вы делаете это в коде, вы получаете обзоры кода, историю коммитов, автоматизированное тестирование, сканирование безопасности и т. д. Все преимущества, которые приходят с вашим процессом разработки и конвейером выпуска. Инструмент и процесс администрирования, которые не отслеживают эти вещи, подобны разработчику, который вносит незапланированные изменения непосредственно в транк, а затем вручную создает и развертывает его в рабочей среде без проверок, тестирования или проверки кода. Вы не делаете этого со своим кодом, поэтому не делайте этого со своей конфигурацией. Это изменение в производстве, и, что еще хуже, это неотслеживаемое изменение в производстве. Когда что-то ломается в результате изменения, исправить его намного сложнее, потому что об изменении, вероятно, не знают нужные люди.

Будь умным, задавай вопросы, избегай лишнего, если можешь

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

Можете ли вы придумать больше сценариев, в которых вам нужно было бы создавать функции администратора? Дай мне знать в комментариях.