Firefly спонсировал этот пост.
ClickOps — позор. Как сообщество, мы должны запретить это. И это должно быть очевидно для любого, кто серьезно относится к облачной инфраструктуре.
Сегодня данные показывают, что 89% организаций утверждают, что они приняли инфраструктуру в качестве кода (IAC), согласно отчету Firefly «Состояние инфраструктуры как кодекса», но только 6% достигли полной облачной кодификации. Эта математика жестока. Он говорит нам, что большинство компаний принимают IAC, и считают, что они организации IAC-зрелища, но все же систематически используют ClickOPS-используя облачную консоль/графические интерфейсы вместо командной строки для управления инфраструктурой.
В целом, как облачные практики, мы нормализовали профессиональную халатность. И это станет намного хуже.
«Чрезвычайная» рационализация
Одна из причин, по которой Clickops — это везде: каждое действие ClickOps помечено как «срочное».
Команды усовершенствовали искусство оправдания ручных изменений консоли по мере необходимости. Но когда большинство организаций делают эти исключения, они больше не исключения. Это просто стандартная рабочая процедура.
Шаблон предсказуем:
- Нарвать все изменения консоли как «срочное».
- Используйте аварийные протоколы для обычных изменений.
- Отказ от восстановления работы, когда непосредственное давление умирает.
- Повторите, пока ClickOps не станет стандартной практикой.
Многие рассматривают изменения консоли как горячее исправление, и, как таковые, они обязаны, в какой -то момент вернуться назад и правильно архитектировать эти изменения. Но критическое слово здесь «обязан» — потому что большинство команд никогда не выполняют.
Лицемерие громкое. Инженерные команды требуют обзоров кода для изменений приложений, но затем нажимают их путь через модификации инфраструктуры, которые могут снизить всю среду.
Правда, с которой мы не хотим столкнуться? Мы остановили Sshing в машины Linux по какой -то причине. Мы должны прекратить клики.
Миф о стадии окружающей среды, в который мы все еще верим
Команды оправдывают ClickOPS в непроизводственных средах по мере необходимости для ловкости, создавая систематический дрейф между средами, которые почти гарантируют сбои производства.
Вы когда -нибудь обнаруживали: «Все работало на моей машине. Все работало в постановке, затем мы развернулись для производства, и внезапно — массовое время простоя»? Это проблема, которые практикуют чаще, чем они хотели бы признать. И часто основная причина заключается в том, что производство регулировалось IAC, в то время как постановка оставалась свободной для всех.
Проверка реальности: оправдание по стадии не прагматизм. Это инженерная халатность, маскирующаяся под гибкость.
Стоимость долга инфраструктуры, управляемого ClickOPS
Clickops создает инфраструктуру призраков, которая в течение многих лет преследует организации.
Представьте себе: три года ненужных расходов облака, потому что кто -то нажал кнопку и ушел. Это не крайний случай. Это предсказуемый результат лечения инфраструктуры, как это, как это сессия отладки вместо инженерной дисциплины.
А для таких компаний, как Figma, компании по разработке инструментов, чье первоначальное публичное предложение недавно выявило массовый счет в размере 300 000 долларов в день, ненужные расходы могут быстро увеличить и стоить вам миллионы.
Оправдание в стадии окружающей среды — это не прагматизм. Это инженерная халатность, маскирующаяся под гибкость.
Помимо затрат на монтаж, что еще хуже, так это составной долг знаний. Инженеры раскручивают окружающую среду, которая сидит в течение многих лет, и их преемники оставляют их нетронутыми, не имея смелости удалить их. В этих сценариях ClickOps не просто создает технический долг. Это создает организационный паралич.
Эпидемия дрейфа конфигурации, объяснена
Несмотря на увеличение внедрения МАК, дрейф конфигурации ухудшается. В отчете «Состояние инфраструктуры в качестве кода» показано: «Состояние инфраструктуры»:
- Менее трети организаций активно контролируют дрейф.
- 17% вообще не имеют процесса обнаружения дрейфа.
- Только 8% имеют автоматизированное инструмент управления дрейфом.
- 40% Из команд сообщают, что дрейф занимает несколько дней до недель, чтобы исправить.
Основная причина очевидна: Частичное принятие МАК смешано с систематическими кликами в основном гарантирует расхождение конфигурации. Это не проблема инструмента. Это проблема дисциплины.
И окно для исправления этих практик быстро закрывается.
Умножение проблемы: многочастотная сложность и ИИ
Задача поддержания безопасного, неизменного, устойчивого облака усиливается в мультиколевых, много-IAC. Сегодня:
- 68% организаций работают в нескольких облаках.
- 57% используют несколько структур МАК.
Различные команды используют разные инструменты, все вносят ручные изменения в взаимосвязанные ресурсы. И это достаточно сложно.
Но через два года будет невозможно решить эти проблемы так, как мы можем сейчас. Когда мы добираемся до места, где агенты искусственного интеллекта запускают облако для нас, если у облачных команд нет очень упорядоченной системы записи и правильных ограждений, кодифицированных для них, они нанесут ущерб. Таким образом, неудивительно, что наличие игрового плана как можно скорее является критически важным.
Профессиональный золотой стандарт: облако как код
Реальные аварийные процедуры требуют немедленных планов восстановления. Когда в пятницу вечером в 2 часа ночи, инженер по надежности сайта находится вне офиса, и вы столкнетесь с неизбежным временем простоя, может потребоваться ручное вмешательство.
Но лучшие и самые гибкие облачные команды:
- Отслеживать экстренные вмешательства.
- Требовать немедленной кодификации.
- Оцените экстренные клики как технический долг, который требует срочного внимания.
- Отклоните удобную ложь, что ClickOps является приемлемой инженерной практикой.
И поскольку состояние отрасли продолжает меняться, ненужная деятельность ClickOps должна исчезнуть, чтобы освободить место для более устойчивых, безрисковых и масштабируемых способов управления облачными средами.
Чтобы узнать больше, загрузите полный отчет «Состояние инфраструктуры 2025 года как код» и изучите, как Clickops влияет на процессы, эффективность и перспективы команд.
Firefly-это плоскость управления облаком, которая позволяет DevOps и командам инженеров платформы сканировать и обнаруживать весь свой облачный след, обнаружение облачных конфигураций, классифицировать активы с использованием политики как код и управлять одним инвентаризацией облачных ресурсов в разных кластерах и Kubernetes Clusters. Узнайте больше последних из Firefly Trending Stories YouTube.com/ThenewStack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Идо Ниман является генеральным директором и соучредителем Firefly, а также бывшим генеральным директором и соучредителем Nuweba, быстрой и безопасной платформы без сервера. К разнообразию ролей, которые он занимал, он приносит более десятилетнего опыта в элите … читайте больше от Ido Neeman
