AS
>А поделитесь практиками, кто как описывает админам/девопсам требования к разворачиваемому ПО?
У нас есть специальный документ с требованиями. Никаких плейбуков не надо.
У нас есть специальный документ с требованиями. Никаких плейбуков не надо.
Size: a a a
2020 July 14
AS
Но он вам, скорее всего, не подойдёт, так как у вас, скорее всего, выкатка - это не установка системных пакетов с накатом конфигурации
AP
ну бывает чего... но иногда уход предшественника необходим так скажем :) но тогда сразу ичего хорошего не жди
Если бы старого техдиректора Аладдина уволили в 2014...2015, все было бы хорошо. Собственник оставил его себе как самого доверенного эксперта. Он ему и напевал, что везде портят и воруют код.
ЮВ
если директор верит этим рассказам, он:
- либо неимоверный кредит доверия этому человеку выдал (надо подумать, почему)
- либо очень огорчился статусом и текущими результатами разработки (и тут вопрос к разработке)
- либо неимоверный кредит доверия этому человеку выдал (надо подумать, почему)
- либо очень огорчился статусом и текущими результатами разработки (и тут вопрос к разработке)
MG
всем привет!
А поделитесь практиками, кто как описывает админам/девопсам требования к разворачиваемому ПО? У нас сейчас проблема (в отсутствие девопса как такового), что приходится админам описывать требования прям подробно, вплоть до конкретных команд в шелле (юзают ansible). При этом один хрен хромает мониторинг, сбор логов и тд, так как стандарта нет, а админы сами его придумывать не будут. В лучшем случае прикрутят стандартные метрики в заббикс/нагиос и ротацию текстовых логов.
Как я себе это вижу: мы прописываем прям стандарт (рецептом можно назвать) для каждого вида софта. Например, для nginx нужно брать конфиги проекта там-то в репозитории, логи писать в текст туда-то и еще отправлять в ELK, мониторинг через готовый шаблон заббикса, обновлять по таким-то правилам. И тд.
Это довольно долго и тоскливо собирать и вылизывать, но на выходе по идее должно сильно добавить прозрачности со всех сторон. В итоге проект будет как набор кубиков для админов - тупо собрать из готовых решений по стандарту. Начнем наверное с простых google docs, разбитых по приложениям, но может есть решения получше? В том числе интересует и дальнейшее сопровождение, так как эти стандарты, очевидно, не статические и должны меняться.
А поделитесь практиками, кто как описывает админам/девопсам требования к разворачиваемому ПО? У нас сейчас проблема (в отсутствие девопса как такового), что приходится админам описывать требования прям подробно, вплоть до конкретных команд в шелле (юзают ansible). При этом один хрен хромает мониторинг, сбор логов и тд, так как стандарта нет, а админы сами его придумывать не будут. В лучшем случае прикрутят стандартные метрики в заббикс/нагиос и ротацию текстовых логов.
Как я себе это вижу: мы прописываем прям стандарт (рецептом можно назвать) для каждого вида софта. Например, для nginx нужно брать конфиги проекта там-то в репозитории, логи писать в текст туда-то и еще отправлять в ELK, мониторинг через готовый шаблон заббикса, обновлять по таким-то правилам. И тд.
Это довольно долго и тоскливо собирать и вылизывать, но на выходе по идее должно сильно добавить прозрачности со всех сторон. В итоге проект будет как набор кубиков для админов - тупо собрать из готовых решений по стандарту. Начнем наверное с простых google docs, разбитых по приложениям, но может есть решения получше? В том числе интересует и дальнейшее сопровождение, так как эти стандарты, очевидно, не статические и должны меняться.
У нас для каждого компонента есть свой компос, с выделенными переменными и всякими правилами, и механизм формирования компоса из набора компосов, типа разные комбинации компонентов. Когда админы выкатывают релиз, то просто собирает нужный им набор компонентов и в ансимбле указывают переменные среды. То есть компонент работает одинаковым способом в разных окружениях, от машины разработчика до прода
AS
Andrey P
Если бы старого техдиректора Аладдина уволили в 2014...2015, все было бы хорошо. Собственник оставил его себе как самого доверенного эксперта. Он ему и напевал, что везде портят и воруют код.
Бхахахаххаха, мяу. Было бы зачем красть
AP
Бхахахаххаха, мяу. Было бы зачем красть
Андрей знает эту историю, потому что эффективный менеджер Батасов в мое отсутсвие начал срочно искать того, кто будет за него работат. Андрея пригласил на собеседование. Но не понял даже уровень Андрея, не смог оценить.
AP
если директор верит этим рассказам, он:
- либо неимоверный кредит доверия этому человеку выдал (надо подумать, почему)
- либо очень огорчился статусом и текущими результатами разработки (и тут вопрос к разработке)
- либо неимоверный кредит доверия этому человеку выдал (надо подумать, почему)
- либо очень огорчился статусом и текущими результатами разработки (и тут вопрос к разработке)
Почему в 1930 верили во вредителей промпартии? Данинг и Крюгер.
AS
Andrey P
Почему в 1930 верили во вредителей промпартии? Данинг и Крюгер.
Может быть, потому, что и вредителей и просто жопоголовых с 1930-х годов и до сих пор полно?
ЮВ
Andrey P
Почему в 1930 верили во вредителей промпартии? Данинг и Крюгер.
да ну ладно вам причины искать в чужой голове :)
ЮВ
и уж тем более странно будет выглядеть позиция "ну щас я всем покажу, кто вредитель"
ЮВ
еще раз повторюсь - терпеть и ДОКАЗЫВАТЬ, не имея на то ресурса — это виктимная позиция.
можешь переломить — ломаешь. не можешь переломить — сбегаешь. а оставаться, но ДОКАЗЫВАТЬ это какой-то self harm
можешь переломить — ломаешь. не можешь переломить — сбегаешь. а оставаться, но ДОКАЗЫВАТЬ это какой-то self harm
ЮВ
мученичество и жертвование. и все пустое
AP
еще раз повторюсь - терпеть и ДОКАЗЫВАТЬ, не имея на то ресурса — это виктимная позиция.
можешь переломить — ломаешь. не можешь переломить — сбегаешь. а оставаться, но ДОКАЗЫВАТЬ это какой-то self harm
можешь переломить — ломаешь. не можешь переломить — сбегаешь. а оставаться, но ДОКАЗЫВАТЬ это какой-то self harm
Да, овчинка выделки не стоит. Вернул бывшему работодателю все как было до меня, и занялся другими делами.
IB
Но он вам, скорее всего, не подойдёт, так как у вас, скорее всего, выкатка - это не установка системных пакетов с накатом конфигурации
Где-то требуется.
IB
Maksim Gorshenin
У нас для каждого компонента есть свой компос, с выделенными переменными и всякими правилами, и механизм формирования компоса из набора компосов, типа разные комбинации компонентов. Когда админы выкатывают релиз, то просто собирает нужный им набор компонентов и в ансимбле указывают переменные среды. То есть компонент работает одинаковым способом в разных окружениях, от машины разработчика до прода
Тааак, похоже на наше целевое состояние. Интересно, как вы создаете новые и меняете текущие
MG
Есть для проекта git репозиторий Docker с компосами из описания выше, любая выкатка - это релиз внутри этого репозитория, со ссылками на MR/commits и в релизе видно что и где поменялось в компосах, к нему же есть описание
MG
Ну и человеческое общение никто не отменял )
NK
Девопс-конторы, - настал ваш звёздный час! У меня есть маленький, но очень гордый заказчик для вас, который делает первый подход к неофициальным прайсам! Стучитесь в личку @ctodsimonov
2020 July 15
AG