Comments 9
11 лет назад я работал в телекоммуникационном провайдере и моя команда начала писать собственную систему автоматического деплоймента для компании. Одна из самых важных фич, из-за которых, собственно, и было принято решение писать свою систему - это детальный план деплоя еще до начала каких-либо изменений на реальных серверах.
То есть, инженер Operations делает какие-то изменения, мы обсчитываем все конфиги и изменения на сервисах/серверах - и показываем какие сервера будут затронуты, какие конфиги будут изменены и тп. Разбиваем все на подзадачи и параллелим, показываем диаграмму Гантта. Если все ок - то начинаем деплой. Если во время деплоя что-то пошло не так - мы поддерживали ролбэк, практически на любой стадии (правда, на него в конце концов стали забивать, поскольку непростое это дело). Windows/Linux, виртуалки и bare-metal.. На момент моего ухода (больше 7 лет назад) мы управляли более 4к серверов на продакшене и, минимум, в 2 раза больше в тестовых окружениях.
Конечно, это не защита от всех ошибок. И, конечно, ошибки были, в том числе и курьезные, и серьезные. Но я считаю, что это уберегло от еще большего количества более дорогих проблем. Наш CTO подсуетился и даже оформил на себя патент :)
На ошибках учимся, хотя иногда цена ошибки может быть довольно высока
видимо позиция senior yaml developer перестанет быть шуткой. Нужно очень глубоко зреть в корень, чтобы делать код ревью таких вещей полностью представляя последствия.
Нужно очень глубоко зреть в корень, чтобы делать код ревью таких вещей полностью представляя последствия.
В данном случае достаточно было бы плагина в IDE с подсветкой/выделением шаблонов и людей, натаскавшихся этот плагин использовать.
Таких людей потенциально гораздо больше, чем аутистов-"сеньоров", натаскавшихся на доступную компутеру механическую работу.
Нужно очень глубоко зреть в корень, чтобы делать код ревью таких вещей полностью представляя последствия.
Главным навыком Senior YAML Tester должен стать минимум прогон шаблонизатора для просмотра финальной конфигурации — salt saltutil.renderer, terraform validate && terraform plan, etc. А потом уже узкие специалисты могут просмотреть и оценить план изменений.
Чему это научило нас ...
(Монолог в никуда) Подождите секундочку, вы (скайсканнер) же так гордитесь(со всем присущим вам британским снобизмом) что вы набираете только сливки(или объедки сливок после FAANG) в свою компанию. Процесс вашего отбора соответствует лучшим стандартам FAANG индустрии, с 10 собеседованиями, 20 упражнениями из спортивного программирования против секундомера. А в результате ваш работник не в состоянии выполнить terraform plan и посмотреть чего он там собрался хераксить в продакшен. Просто шикарно ...
То есть отсутствие фигурных скобок вызвало все вот это вот?
И при этом человек который внёс изменения допустил это и далее по цепочке? И изменения не были протестированы? Как так вообще?
Как одна строка удалила 478 микросервисов Skyscanner по всему миру