Comments 124
(высовываясь из-за асбестовой плиты) а, так вот о чём была предыдущая статья.
Да, но нет. То есть, да, в менеджменте много кто считает примерно так, как тут описано, но нет, эта статья не поможет, потому что менеджмент её читать не будет. И следующую за ней тоже не будет читать. И возврат к узкой специализации не поможет, потому что при ней был тот же самый результат, только из-за «с моей стороны пакеты вылетели, проблемы на вашей стороне», и упирается это всё снова в менеджмент.
Я понимаю боль автора, так как сам являюсь девопсом. Девопс не должен быть прежде всего девом или опсом. Девопс это практика, культура в конце концов.
У всех девопсов разные навыки и сильные стороны кто-то в прошлом был дба админом, кто-то сис. администратором, разработчиком итд итп.
меня тут недавно чел из ИТ (системщики, вари, и прочие центосы)
а научи ка ты меня bgp и vxlan по быстрому, а то в моих вакансиях начали появляться эти буковки
посмотрел — действительно начали появлятся
стало интересно кого они находят
П.С. я не считаю что эти технологии сложные, вовсе нет, вполне по силам/времени сетевику мидлу или на базовом уровне синьору околосетевику
П.П.С еще одно интересное наблюдение — эти технологии — необслуживаемые, те неспецу туда лезть просто не нужно так как и так работает
в них несетевку даже на show делать нечего
Если devops поставили задачу, где реально нужен «bgp и vxlan», а он сделал «костыли в виде 30 nginx куче хапрокси и ингрессов в истио» то проблема в квалификации devops. Если devops не знает, что тут нужен «vxlan», то менеджер не знает этого тем более.
С другой стороны, если devops скажет, что тут нужен vxlan и что он его сделает за месяц, а консультант за 2 часа, то тут даже хомяк правильное решение примет.
Понятное дело, что devops не обязан быть крутым сетевиком. Но и менеджер тоже им не обязан быть. Поэтому обвинять менеджера в том, что появились « костыли в виде 30 nginx куче хапрокси и ингрессов в истио» это очень странно.
А кто менеджеру сказал, что он экономит? Откуда ему знать, что devops такую задачу решить не может? Вот если бы devops (да и разработчики) говорили — «я такое делать не умею, будет провал», то жить было бы намного проще.
Обычно говорят, и даже "невозможно", но "вы же профессионал — подумайте и сделайте"ю С другой стороны "не умею" ещё не означает "будет провал".
но "вы же профессионал — подумайте и сделайте"ю
не хватает ролика про пять красных взаимно перпендикудярных линий, две зеленым, три прозрачным и одна обязательно в виде котика )))) )))
Паша сам виноват, что работает у… не очень умных людей
отлично сваливаем с больной головы на здоровую
Либо не способен донести свою точку зрения и повлиять на решения.
есть такое, но проблема более общая… И была описана в статье [«Красная» корпоративная культура — главная проблема российского бизнеса (Часть 1)] (https://habr.com/ru/post/483876/) (внезапно! сюрприз! у нее другой автор, не тот же, что и настоящей статьи, но со схожими мыслями)
если их у вас 30-100 то да можно и позвать
если 3-5 и больше тысяч портов то консультант будет жить на сайте (за стоимость инсайт*4)
а если непривидикошка еще и нестабильный энвайромент (не в смысле стабильности а в смысле непрерывных изменений) — то и несколько
все очень зависит.
я про то что в девопс пытаются впихнуть заведомо там не лежащее
поэтому и не понятно
причем — видел объяву где только они (собственно оно и стало прообразом моего изначального сообщения) — без дополнительных технологий (IP, routing, switching, ...)
иногда складывается впечатление что роботы сидят не на первичном отсеве резюме а на составлении требований к вакансиям
Вот что опсов теперь код в прод писать заставили — это проблема.
Теперь просто Ops-ам не платят за Ops-работу, а требуют фичей в проде от них — к повышению стабильности сервисов это не ведет.
И работу опсам найти почти невозможно стало — либо работай по 12 часов в день (6 занимаешься продом, 6 кодишь, потому что ты не разработчик и кодишь намного медленнее), либо работай за копейки 24/7 в мелкой конторе.
Вот и весь результат «девопсизации» на практике. Разделение труда не зря придумывали, мне кажется.
На практике намного чаще те самые «девопсы» (уж простите за неправильное использование этого слова в данном случае, но это не я такой, меня заставили) внедряют всякую никому неизвестную новую финтифлюшку ничего не документируя, а через год убегают на следующее место работы. А старый отдел опсов сидит где-то рядом и в поте лица пишет продовый сервис, сжигая в топке свой многолетний полезный опыт, потому что они теперь разработчики по должности и каждый квартал с них спрашивают, как с разработчиков.
Бха-ха-ха-ха.
Все эти «индастри стандарты» на практике в каждой отдельно взятой компании настолько переписаны и переделаны, что никакого универсального опыта нет и быть не может.
Крупные технические компании уже плюнули на это и все до единой написали свои «куберы», например.
> Но 20 лет назад это был некий магический баш и магические заклинания в консоли, что превращало админа в полубога
20 лет назад уже был cfengine (и работал не менее прекрасно, чем сейчас). Teamcity появился в 2006 и идея CI/CD к тому моменту уже не была свежей и новомодной. Контейнеры были (jail в bsd, чруты с обвязками в линуксах) — разве что не было чего-то вроде registry (но были аналоги для локальных нужд). Пакеты и вовсе появились <я не настолько старый> знает когда, и сервисы отлично ими деплоились и 20 лет назад, и сейчас.
Было бы желание. Мы вот пакетами лет 15 деплоились — и ничего, не померли. CD был всегда, сколько я помню, CI лет 15-20 назад стал полностью автоматическим (хотя автоматику многие выключали и каждый раз нажимали кнопку, наблюдая за процессом).
> и магические заклинания в консоли
Вот только необходимость в использовании этих знаний никуда не пропала, а для разработчиков они всё такие же магические.
А для хороших разработчиков магическими они не были ни тогда, ни сейчас.
И, повторюсь, нужно разделять труд. Знания разделять не нужно. Монотонный процесс разработки, в котором очень важно не отвлекаться, очень хреново проходит, когда каждые полчаса у тебя пиликают сообщения от мониторинга, которые броадкастом шлются по всем, а не в одного дежурного, который подергает конкретного человека, если случилось что-то реально важное. А сейчас даже если и дежурный есть — то прекращать писать код на дежурстве ему никто не разрешал.
> и заканчивая упрощением кадрового вопроса.
Это единственное, что реально решает девопс в текущем его виде у нас на рынке. Правда, сотрудники почему-то выгорать стали намного быстрее и синяки у всех черные под глазами — но кому какое дело, правда?
Главный вопрос — зачем?
Ответьте на него, а потом рассказывайте про прекрасную реальность, в которой ничего никогда не ломается, сеть не тормозит, рейды не разваливаются (а виртуалки в чужой инфре не уходят в кому с невнятными симптомами) и в сервисы на лету никто никогда не лезет руками.
Есть DevOps как по книжке — там всё хорошо и прекрасно. Но на практике это сказочный единорог, с которым вы в реальной жизни не столкнетесь, особенно если вы опс.
Потому что конечная цель «девопсизации» на местах — сэкономить на персонале и выжать последние соки из сотрудников. А в книжках всё чудесно, да. Только никто о качестве не думает — оно вроде как само работает, запас прочности сейчас у всех систем огромный.
Ну и вопрос «наследственности» тоже очень важен. Уход «незаменяемых» людей всегда болезненен. А если вся их работа в репозитории, то всё становится в разы проще.
Угу. Теперь все проблемы эксплуатации становятся проблемами разработчиков, ведь эксплуатацию уволили ещё в самом начале. Если из этих опсов кто-то остался кодить дальше — повезло, он что-то может починить (через маты, потому что теперь он без премии за закрытые таски будет сидеть), а если нет — то ой, до первой серьёзной проблемы.
> Одно это резко увеличивает качество продукта
Качество продуктов увеличилось только и только потому, что технологии стали намного стабильнее, сервера — быстрее, а железо на практике — надежнее и холоднее.
Весь тот *здец, который сейчас пишут, на серверах и линуксе 2010 тупо не работал бы, падая раз в несколько часов целиком, унося с собой всю железку в кому, watchdog-и жрали бы больше ресурсов, чем сами сервисы.
Отдельный софт вообще перестал сам по себе падать (его systemd перезапустит, если что), а контейнеры регулярно перезапускаются с флашем, не давая накопиться проблемам — вот и весь секрет «стабильности». Влияет и то, что монолитных огромных сервисов стало меньше — но при чём здесь devops?
А код отдельные люди плохо писали и тогда, и сейчас. И банальные ошибки делали и тогда, и сейчас. И разработчик, который полночи чинил прод, а утром пришел к 10 утра делать таски делает таких ошибок ещё больше.
А всё, про что вы пишете — «IaaC, CI/CD, централизованый и прозрачный мониторинг и логирование всего и вся» — это часть SRE как раз и существует достаточно долго. Хоть это и часть девопс-культуры, но далеко не решающая. В SRE наоборот эксплуатация возведена в абсолют и любой разработчик может прозрачно в это погрузиться (если пожелает). И SRE погружены в разработку — но не пишут бизнес-код.
И контейнеры были в 2005м. Собирать посложнее было (хотя для сборки были те же sh-ники, один в один повторяющие то, что сейчас пишут в докер-файлах) и деплоить было чуть менее удобно — слоёв не было. А у сишников вообще была статическая сборка со всеми либами внутри бинаря (привет, «главное преимущество Go»), в системе только libc нужен был и порт свободный правильно выбрать.
> Ответственность за поставку живых контейнеров стала ответственность
Ага, осталось только понять — кому они их поставляют.
Пакет описывался один раз и менялся только с появлением новой убунты, контейнеры не менялись вообще почти никогда.
И деплоить было чем. Только почему-то никто не хотел автоматом — все просили релиз-инженеров и по остаточному принципу таковыми всегда были дежурные опсы (ну или просто опсы).
Говно за забор перекидывали только отдельные люди — и перекидывать они его не перестали. Только они теперь не на админов ноют, а на облака, которые плохо работают.
Нихрена не поменялось.
Зависимости пакетов на что людям даны?
> mysql
Стоит на отдельных серверах, которые управляются отдельной автоматикой, вообще не обсуждается. И для дева тоже.
> php.ini,
Прекрасно деплоится пакетом service-name-config
> в результате невозможностью запустить на этом же сервере что-то другое с другой версией
Даже PHP можно было поставить на сервер далеко не одну версию, с остальными языками было ещё проще.
Опять же, зачем при наличии дешевой виртуализации ставить несколько сервисов в одну систему? Они ставились вместе только если работали на одном стеке. Ну или в виртуалэнвах-чрутах, опять же.
> А всё это часть комплексного вопроса, который и делал сложным разворачивание с нуля полного стека для тестирования
Стек для тестирования поднимался ops-ами рядом с продом в необходимых масштабах и полностью повторял прод.
И всё это при условии, что использовались пакеты, а не чруты — тогда вообще не было отличий от того, что вы наблюдаете сейчас.
> Что приводило с простаивающим 90% времени серверам
Ну а теперь сервера загружены на 110% и постоянно что-то где-то тормозит и стреляет.
Сервера были загружены ровно настолько, насколько позволяли бюджеты. И инструменты для размазывания виртуалок по кластеру на свободные ноды тоже были (и я даже свою пытался написать в company-wide — оказалось, что там уже штук 10 было запущено). И openstack уже выглядывал из будущего RHEV-ом и эвкалиптом, чтобы разработчики не думали о железе.
Что вы пытаетесь рассказать нового и чудесного, с чем я не сталкивался до того, как в наш мир ставшее паразитным слово «devops»? Ничего нового с точки зрения технологий или конкретных практик в девопсе нет — это всё почти полностью повторяет SRE-культуру. А сама методология у нас была извращена и обращена на пользу работодателю — хотя упрощать жизнь она должна как раз техническим специалистам.
Весь девопс — он в том, чтобы у админов и разрабов чатик был один на всех. Всё. Вы внедрили девопс, поздравляю. А остальное — просто технологии, которые можно внедрять силами админов-девопсов-разрабов-когоугодно-хотьCTO.
Что приводило с простаивающим 90% времени серверам
сервера никуда не делись. От того, что они теперь у провайдера — Вы за простаивающие сервера не перестали платить. Просто Вы теперь платите х2-х3 )))) С другой стороны — если облако правильно использовать — можно экономить. Речь именно про короткоживущие тестовые среды и про ситуации, когда нужно много ресурсов и еще вчера (например, готовимся к "черной пятнице"). С другой стороны, контейнеры ничего нового не придумали — раньше можно было точно так же деплоиться виртуалками в омозоне. Ну, ок — деплой будет не 5 минут, а 15 — но кого это волнует на самом деле? А гипер-оптимизация ресурсов с помощью контейнеризации ведет к дополнительным технологическим проблемам. Вроде такого. Неудивительно, что сейчас активно развивается направление "легковесных виртуалок"
Ну а забыли уже про список software requirements на сервере? От какой-нибудь конкретной версии PHP/mysql и заканчивая конкретным php.ini,
от того, что проблему замели под ковер — она не исчезла. С одной стороны — да, действительно теперь можно задеплоить два контейнера с разными наборами пхп пакетов и жить спокойно. Но при этом внутри каждого из контейнеров точно так же может быть помойка из различных версий и точно так же надо решать ситуацию с конфликтом зависимостей, если два необходимых пакета зависят от двух несовместимых версий третьего. Да и для разработчика сбора образа — это такая магия. Когда чего-то варим и оно даже вроде работает. Про эффективность речи не идет.
на вагранте сидели, жалоб не было.
А главное их легко поднять любому деву
это не так. В частности, весело будет маководам, после того, как эппл на арм пересядет ) Я уж не говорю про специфичные вещи вроде низкоуровневых штук или всяких эластиков, которые требуют донастройки хостовой машины
Ну деплой типичных контейнеров секунды, а не 5 минут.
я соглашусь, что время развертывания ВМ больше. Но даже деплой контейнера не секунды, а скорее десятки секунд (плюс время на скачивание новых образов — а оно может быть минутами)
Маководам и на интеле весело, когда вся инфраструктура — ipv6-only. Контейнер-то они запускают, а сходить он никуда не может.
Допустим образ питона на базе alpine.
Совершенно верно, но всё это теперь является проблемой разработчика, а не опса :)
почему все ещё на него не едут
потому что не стабилизировалось еще ?
Но пока курить ходил, вспомнил, что nesting kvm работает плохо, так что вся эта история — она для тех, у кого своё железо. Ну или покупать отдельные виртуалки на minikvm, но там один хостер и для потребителя разницы нет.
Но помнить про него надо — полезная штука.
Современный стек позволяет кардинально проще решать вопросы тестирования
и да, и нет. Действительно тесты сейчас стали писать чаще на код. И даже хорошие тесты. Но не всегда. Потому что цифирка 100% в coverage НИЧЕГО не означает. И не дает гарантий, что ваш продукт не завалится в продакшене.
относительно легко разворачивая новые билды на части живого трафика причём, что важно, без участия каждый раз эксплуатации
и да, и нет. С одной стороны — это делали на вышеупомянутых магических баш скриптах и тимситях, с другой — действительно сейчас для определенного подмножества задач это стало проще в связи с устаканиванием стека инструментария. Тот же истио. Но все равно сделать настоящее тестирование на живом трафике даже сейчас это та еще история. И вопрос цены. Весь этот инструментарий требует и поддержки, и ресурсов серверов. А завтра выйдет какой-нибудь новый кубернетес и будет не модно работать в вашей компании, которая на него не мигрирует и все опять повторится )
Прочитал тред и пришёл к выводу, что у вас, джентельмены, травмы разные. Я вот тоже никогда не видел увольнения/переквалификации ops и найма на замену т.н. «devops»-инженеров/разработчиков. Почти всегда этот «devops» строился параллельно имеющейся службе эксплуатации ибо она была не в состоянии эксплуатировать, а те, кому это мешало, были не в состоянии эту службу починить из-за страха или блокирующего менеджера где-то наверху.
Опять же, посыл «это ваше программирование меня не волнует, дайте мне sendmail настраивать до потери сознания» я тоже разделить не могу, потому что постоянно бьюсь головой о разработчиков с таким же по сути посылом «эта ваша эксплуатация меня не волнует, я код написал/образ собрал, дальше давайте сами». В ИТ эксплуатируется в основном код, и основная цель кода — быть эксплуатируемым, ибо просто лёжа в VCS он никакой пользы не доставляет. DevOps призван как раз это «с моей стороны пули вылетели» чинить, не отменяя при этом специализацию.
А то, что на самом деле происходит вместо этого — так в первый раз, что ли. Раньше был такой же без головы внедряемый agile, сейчас вот ML в мониторинге, ещё скоро observability подъедет в Россию. Про последний прямо предвкушаю, как удивительно его будут реализовывать на местах.
Писать код для новых фич в бизнес-сервисе — это НЕ Ops. Ops-ы плохо пишут код по чужим ТЗ, они этому не учились и это сложно. Потому что для самого себя ты рисуешь ТЗ исходя из своих возможностей.
Только, опять же, никакой девопс для этого не нужен — нужна нормальная атмосфера в коллективе и тайм-слоты под внутренние задачи/рефакторинг.
А сейчас все пишут бизнес-код, пока что-то не на*тся. Навернулось — починили, бросились дальше писать фичи. Вот что такое девопс.
Связно писать на русском языке тоже сложно, так что теперь, отменить русский письменный для отдельных категорий граждан? Все всё сначала делают плохо, даже ходят никак. Потом учатся и начинают делать хотя бы приемлемо. Человек, который пишет бизнес-код и имеет опыт его непосредственной эксплуатации, бесценен ибо редок. А если Вас в процессе каждые полчаса мониторинг дёргает — так может сначала мониторинг починить?
Выключить, убрать прерывающие нотификации, переделать так, чтобы в случае запроса больших объёмов не орало. Если кто-то не может починить проблему, про которую орёт мониторинг, он не должен получать уведомление о ней. По постановке я не могу, то есть и уведомлять меня о ней не нужно.
Руководство вправе ожидать, что я знаю, когда совсем лежит, а не когда LA там 100%. Поэтому я в какой-то момент пошёл и выключил везде все алерты на нагрузку CPU, сети и диска как недостаточно специфичные.
Очень грубо, не более числа ядер CPU в системе.
Это как-то уж ну очень грубо. Прямо матом =)
LA, который не превышает количество ядер CPU в системе обычно означает, что всем процессам хватает процессора и никто его никогда не ждёт. Или сервер, из под которого резко вынули хранилище (не локальное, само собой) и количество процессов, работавших с этим стораджом, совпало с количеством ядер =)
Ничего бесценного в таких людях нет, судя по зарплатам. Получают процентов на 10-20 больше разве что.
Намного важнее ценится манагерский скилл — языком поговорить, ТЗ расписать, от коллег чего-то добиться — вот он может зарплату и на три помножить. А ops-опыт на зарплату не влияет.
> так может сначала мониторинг починить?
А тут мы и приходим к вопросу, который я задал уже раз 30 — кто во всей этой схеме фундаментально чинит проблемы, которые приводят к загоранию мониторинга? Разработчику за это не платят никогда и он идёт по пути наименьшего сопротивления — чинит проверку, делает костыль или просто тушит надоедливую проверку.
А моргающие триггеры — это как раз нормально, иначе у тебя либо сервис на локалхосте, который мониторится с локалхоста, либо у тебя нет никакого мониторинга и ты не в курсе реальных проблем.
А админы в СТО давно уже не попадают, уходя в более простой путь разработчиком работать.
Ну если только деньгами измерять, то лучше веществами торговать, чо уж там. Нефтью, например, или газом.
Про починку проблем — да, техдир, удваиваю. Только я никогда не видел не-бумажного техдира. Зато один раз видел человека, которому было настолько не пофиг, что он докапывался до всех, от разработчиков до сетевиков, с целью починить влияющие на пользователей факторы (Виталий, привет, ты в телевизоре).
А моргающие триггеры — нихрена не нормально. У меня этих локалхостов было под сотню, и каждый ниачомный алерт я считал личным оскорблением. Во-первых, кроме меня их получали мои коллеги, и у меня нет причин портить жизнь ещё и им. Во-вторых, если не бороться с никчёмными алертами, к ним привыкаешь и начинаешь их игнорировать. А потом начинаешь игнорировать и другие, нормальные алерты.
А ведь действительно не техдир, что это я. В некоторых организациях есть такой directly responsible individual, который может быть кем угодно, но он а) ровно один, б) отвечает за доставку некоторого результата (фича, кусок инфраструктуры), в) имеет все необходимые права для этого. Но для этого всего и в менеджменте, и на местах должны быть люди с головой, что и приводит опять к C-level товарищам, которые должны это обеспечивать.
Чтобы нефтью или газом торговать — учиться надо было другому. И связи иметь. Да и не все торговать умеют, опять же.
> А моргающие триггеры — нихрена не нормально.
Моргающие триггеры — это нормальная история и от неё не избавишься. В большом проде постоянно что-то меняется и что-то с каждым релизом может сломаться. Не говоря уже о том, что сеть может кончиться когда угодно и где угодно. Чинить моргающие триггеры нужно, само собой — они не просто так возникают.
Я говорю о том, что «дежурный разработчик» будет чинить не проблему, а именно лампочку в мониторинге — порестартит что-то, лимиты поменяет или вообще выключит проверку, а до проблемы докапываться не будет — ему нужно свои таски по разработке доделать. Если вообще будет что-то делать, а не просто увидит, что лампочка погасла и можно дальше заниматься таском (вот только из контекста он уже выпал и время потерял).
Зачем вы ставите дежурными таких людей?
С ростом событий в системе растет число необычных событий, которые приводят к алертам и проблемам.
А нормальные алерты — повод переписать логику алертов.
:)
Сколько кубспреев 2017 года стоит без обновлений, потому что хрен его знает как обновить без смерти прода.
Или «ааа спасите у нас монга в кубере и кассандра» — и потом ты радуешь людей потерей данных за 5-10 часов.
но да всё просто и легко.
Просто не реально просто и легко, открыл и всё понятно.
А ещё прикольнее тераформ на 15-20к строк, это вообще проще некуда.
зачастую проще вообще с нуля всё писать, и переносить всё в 0, что опять же 2-3 недели, но раньше было существенно меньше сервисов ненужных, а сейчас зачастую только nginx это 30-50 контейнеров.
переписать всегда проще по документации / исходникам, чем по чёрному ящику
по спецификации — да
по документации — нет (она может быть неполной, неточной и прочее), но наличие доки лучше, чем ее отсутствие (по крайней можно восстановить часть процессов)
по исходникам — очень сильно зависит от того как они написаны. Вот у меня перед глазами есть макаронный код на пыхыпы. Чтобы разобрать его понадобится не одна неделя работы, т.к. доков нету, явно есть "мертвый" код, точки входа не ясны (точнее не так — точки входа понятны, но опять же непонятна логика взаимодействия). Так что здесь все равно применять те же методики "черного ящика", "белого ящика" и "серого ящика". А это мы еще не рассматриваем обфусцированный код )))
Я им намекнул немножечко, куда идти, но кто-то им в итоге это сделал, хым.
Сколько кубспреев 2017 года стоит без обновлений, потому что хрен его знает как обновить без смерти прода.
хуже. Через 1 год этот кубспрей превращается в тыкву, т.к. сертификаты протухли. Хотя… наверное, на свежих установках эту проблему решили (зато есть куча других)
Это было задолго до хайпа devops. CFEngine в 93 появился, puppet в 2005. Использовались админами вполне. Но почему-то теперь во время хайпа, считается что админы внезапно перестали это делать, а придут девопсы (которых не существует, на самом деле придут админы) и внезапно внедрят инфраструктуру как код, они и 20 лет назад это делали.
Я и не говорю, что старые инструменты были лучше или такие-же. Я про ваши тезисы:
- "речь про других опсов, которые придут потом и по гиту всегда могут посмотреть, чем занимался предыдущий опс и что конкретно и как он делал"
- "что бы сделать работу непонятных админов прозрачной и повторяемой другими людьми"
- имеется в виду devops: "На моей практике эта тема про IaaC, CI/CD, централизованый и прозрачный мониторинг"
Все это было, до хайпа devops. И говорить что это нам devops принес инфраструктуру как код или CI/CD, а "непонятные" админы раньше бегали и все руками настраивали на мой взгляд неверно.
Теперь "непонятных" админов называют devops, и по моему субъективному опыту мало кто из разработчиков поймет, что там в репозитории описания инфраструктуры творится. Разработчиков бы с docker подружить уже победа, а говорить о всяких ansible, puppet, bolt, chef, salt, terraform, pulumiи т.д. вообще не приходится. Понятны и прозрачны ли будут разработчику все твои yaml для kubernetes, helm чарты, mutating webhook на golang, правила для prometheus? Я так не думаю.
Да даже для другого опса это может стать проблемой, когда нет документации к этому коду, или он вообще не знаком с этим. Например работал он все время на ansible и docker swarm, пришел в другую компанию, а там puppet, pulumi и kubernetes, и весь код на puppet dsl или typescript — для него это будет темный лес, поэтому про прозрачность это очень условное утверждение.
Добавлю, что задача "Задачу «быть способным поднять всю инфраструктуру из скрипта» массово начали ставить лишь лет 7 назад" не так уж необходима, как нам ее продают. Для начала — чтобы что-то описать в виде IaC это самое нужно иметь в каком-то описываемом виде. И зачастую быстрее руками что-то поднять и проверить как оно работает, а потом уже переносить в IaC с дополнительной проверкой того, что то, что мы описали на самом деле то, что мы хотели. Только в каких-то вырожденных и простейших примерах можно менять сам IaC и получать ожидаемый результат (либо будет очень много экспериментов).
Вторая история заключается в том, что IaC нужно поддерживать в актуальном состоянии. Скажем, написали вы год назад код на терраформе для поднятия в яндексе тестового стенда. Ну, надо было показать заказчику. Условная трудоемкость неделя (чтоб красиво каталось, без ошибок, надежно). Год вообще не трогали. Вопрос — сможете ли раскатать тестовый стенд сейчас? Очень вряд ли — начиная от того, что поменялось почти наверняка АПИ самого яндекса и кончая тем, что версии терраформа и провайдеров тоже поехали. А на словах было красиво, да.
Поэтому можно попросту описать критерии применимости IaC: это в первую очередь большие масштабы (когда речь идет о сотнях и более однотипных узлов, это точно не про шаурмячную у Васяна), необходимость часто разворачивать однотипные окружения (тестовые, разработческие и пр.), возможность поддерживать это в актуальном состоянии (выделяем время и бюджет на это).
Еще одна статья где автор по неясной причине отождествляет свой опыт с мировым, если у автора есть проблемы напишите лучше в статье как их решали (если решали) чем просто посылать лучи ненависти в разные стороны
свой опыт с мировым
Мы вроде как в России и обсуждаем проблемы России? Нет?
Хотя интересный и любопытный факт — зарубежом ТОЖЕ говорят о проблемах карго-культа внедрения agile/devops/гибких практик, переработках, криво поставленных задачах, низком качестве кода и пр. пр. пр.
Смотрите прекрасный доклад Valarie
виновата методика или ее реализация в конкретной конторе?
Это, знаете ли, политический вопрос в духе — а плохой ли коммунизм или его попросту криво построили в отдельно взятом государстве? Потому что даже в том случае, если Вы найдете примеры "успешного девопса" (а вот попробуйте — только не рекламные буклеты), то запросто может оказаться, что в таких компаниях просто не считают деньги на айти и тогда вопрос эффективности вложенных средств… не стоит.
Автор — бегите вы из этого бизнеса, пусть он загнется и вместо него вырастет новый, без этих бездарей-менеджеров.
Говорят что это ТС, теперь все понятно
https://mobile.twitter.com/_autister/status/1076020478995845125
Понятно что именно?
Понятно, что если на корпоративе кого-то напоят дешёвой хренью (хотя вроде сначала пытался отказаться), а потом сделают удачные фоточки, то найдутся недалёкие люди, которые и через 100 лет попытаются этим в лицо ткнуть.
статья то же самое, много бессмысленной воды
Например сегодня человек написал аналог discp на скале, так как ему нужно было из s3 to hdfs кидать.
Или ещё один умник в Airflow DAG запустив pip install
Все так, все верно. Но это можно обобщить. В любой отрасли так, есть умные начальники и не очень подчиненные. И начальники "конечно" не виноваты в случае провала… не буду рассказывать почему. В американских компаниях это в основном не в таких зашкварных формах, но тоже есть. Как минимум у них все начальство подряд не лезет в процессы на уровне конечных команд и не делится "идеями".
Мало кто признает свои ошибки, начальство особенно, потому что эти люди особенно гордые. Но не стоит забывать, что если же ты признаешь свою ошибку — сразу набросятся "коршуны" в виде народных масс, знающих как надо. Вот так и балансируешь...
Вообще чем дальше, тем все обростает все больше и больше уровнями абстракции. Сначала ОС на железяке, потом на нее какой-то Proxmox-Openstack, потом наверх виртуалки, потом Кубернетис, потом Докеры… а необходимость в знаниях Линукса никуда особо не делись, нужно же ведь понимать и знать. Сложно понять, как оно джунам сейчас, по ходу мрак-мрачный. Все ускоряется, на документацию времени нет, читаешь очень поверхностные ридми и погнали в прод.
DevOps или как мы теряем заработную плату и будущее IT-отрасли, часть вторая