company_banner

Путь разработчика в SRE: зачем идти в инфраструктуру и что из этого выйдет

    Около года назад я переквалифицировался из .NET-разработчика в SRE. В этой статье делюсь историей о том, как группа опытных разработчиков отложила в сторону C# и пошла изучать Linux, Terraform, Packer, рисовать NALSD и строить IaC, как мы применяли практики экстремального программирования для управления инфраструктурой компании, и что из этого вышло.




    В Додо Пицце больше 600 пиццерий в 13 странах мира, а большая часть процессов в пиццериях управляется с помощью информационной системы Dodo IS, которую мы сами пишем и поддерживаем. Поэтому надёжность и стабильность системы важны для выживания.

    Сейчас стабильность и надёжность информационной системы в компании поддерживает команда SRE (Site Reliability Engineering), но так было не всегда.

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


    Много лет я развивался как типичный fullstack-разработчик (и немного scrum-мастер), учился писать хороший код, применял практики из Extreme Programming и старательно уменьшал количество WTF в проектах, к которым прикасался. Но чем больше появлялось опыта в разработке ПО, тем больше я осознавал важность надёжных систем мониторинга и трейсинга приложений, качественных логов, тотального автоматического тестирования и механизмов, обеспечивающих высокую надёжность сервисов. И всё чаще стал заглядывать «через забор» к команде инфраструктуры.

    Чем лучше я понимал, в какой среде работает мой код, тем сильнее удивлялся: автоматические тесты на всё и вся, CI, частые релизы, безопасный рефакторинг и коллективное владение кодом в мире «софта» уже давно обыденны и привычны. При этом в мире «инфраструктуры» до сих пор нормально отсутствие автоматических тестов, внесение изменений в продакшн системы в полуручном режиме, а документация часто есть только в головах отдельных людей, но не в коде.

    Этот культурный и технологический разрыв вызывает не только недоумение, но и проблемы: на стыке разработки, инфраструктуры и бизнеса. С частью проблем в инфраструктуре сложно бороться из-за близости к «железу» и относительно слабо развитых инструментов. Но остальное вполне можно победить, если начать смотреть на все свои Ansible-плейбуки и Bash-скрипты как на полноценный программный продукт и применять к ним те же требования.

    Бермудский треугольник проблем


    Однако я начну издалека — с проблем, ради которых все эти пляски нужны.

    Проблемы разработчиков


    Два года назад мы поняли, что большая сеть пиццерий не может жить без собственного мобильного приложения и решили его написать:

    • собрали классную команду;
    • за полгода написали удобное и красивое приложение;
    • подкрепили торжественный запуск «вкусными» промоакциями;
    • и в первый же день благополучно упали под нагрузкой.



    Косяков на старте было, конечно, много, но больше всего мне запомнился один. На время разработки на продакшене был развёрнут один слабый сервер, почти калькулятор, который обрабатывал запросы с приложения. Перед публичным анонсом приложения его нужно было увеличить — мы живем в Azure, и это решалось нажатием одной кнопки.

    Но эту кнопку никто не нажал: команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение. Они решили, что следить за продакшеном «некритичного» сервиса — обязанность команды приложения. А разработчик бэкенда (это был его первый проект в Додо) решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.

    Тем разработчиком был я. Тогда я вывел для себя очевидное, но важное правило:
    Если хочешь, чтобы твоё приложение жило долго и счастливо, внимательно следи за тем, где и как оно выполняется на проде. Даже если для этого есть специально обученные люди.

    Сейчас это не сложно. В последние годы появилось огромное количество инструментов, которые позволяют программистам заглянуть в мир эксплуатации и ничего не сломать: Prometheus, Zipkin, Jaeger, ELK стек, Kusto.

    Тем не менее у многих разработчиков до сих пор есть серьёзные проблемы с теми, кого называют инфраструктурой/DevOps’ами/SRE. В итоге программисты:

    Зависят от команды инфраструктуры. Это вызывает боль, недопонимание, иногда взаимную ненависть.

    Проектируют свои системы в отрыве от реальности и не учитывают, где и как будет выполняться их код. Например, архитектура и дизайн системы, которая разрабатывается для жизни в облаке, будет отличаться от дизайна системы, которая хостится on-premise.

    Не понимают природу багов и проблем, связанных с их кодом. Особенно это заметно, когда проблемы связаны с нагрузкой, балансировкой запросов, сетью или производительностью жёстких дисков. Разработчики не всегда располагают этими знаниями.

    Не могут оптимизировать деньги и другие ресурсы компании, которые используются для поддержания их кода. По нашему опыту бывает так, что команда инфраструктуры просто заливает проблему деньгами, например, увеличивая размер сервера БД на продакшене. Поэтому часто проблемы кода даже не доходят до программистов. Просто почему-то инфраструктура начинает стоить дороже.

    Проблемы инфраструктуры


    Сложности есть и «на другой стороне».

    Сложно управлять десятками сервисов и окружений без качественного кода. У нас в GitHub сейчас больше 450 репозиториев. Часть из них не требует операционной поддержки, часть мертва и сохраняется для истории, но значительная часть содержит сервисы, которые нужно поддерживать. Им нужно где-то хоститься, нужен мониторинг, сбор логов, единообразные CI/CD-пайплайны.

    Чтобы всем этим управлять, мы ещё недавно активно использовали Ansible. В нашем Ansible-репозитории было:

    • 60 ролей;
    • 102 плейбука;
    • обвязка на Python и Bash;
    • тесты в Vagrant, запускаемые вручную.

    Всё это было написано умным человеком и написано хорошо. Но, как только с этим кодом стали активно работать другие разработчики из инфраструктуры и программисты, выяснилось, что плейбуки ломаются, а роли дублируются и «обрастают мхом».

    Причина крылась в том, что этот код не использовал многие стандартные практики в мире разработки ПО. В нём не было CI/CD-пайплайна, а тесты были сложными и медленными, поэтому всем было лень или «некогда» запускать их вручную, а уж тем более писать новые. Такой код обречён, если над ним работает более одного человека.

    Без знания кода сложно эффективно реагировать на инциденты. Когда в 3 часа ночи в PagerDuty приходит алерт, приходится искать программиста, который объяснит что и как. Например, что вот эти ошибки 500 аффектят пользователя, а другие связаны со вторичным сервисом, конечные клиенты его не видят и можно оставить всё так до утра. Но в три часа ночи программистов разбудить сложно, поэтому желательно самому понимать, как работает код, который ты поддерживаешь.

    Многие инструменты требуют встраивания в код приложения. Ребята из инфраструктуры знают, что нужно мониторить, как логировать и на какие вещи обращать внимание для трейсинга. Но встроить это всё в код приложения часто не могут. А те, кто могут, не знают что и как встраивать.

    «Сломанный телефон». В сотый раз объяснять, что и как мониторить, неприятно. Проще написать общую библиотеку, чтобы передать её программистам для переиспользования в своих приложениях. Но для этого нужно уметь писать код на том же языке, в том же стиле и с теми же подходами, которые используют разработчики ваших приложений.

    Проблемы бизнеса


    У бизнеса тоже есть две большие проблемы, которые нужно решать.

    Прямые потери от нестабильности системы, связанной с надёжностью и доступностью.
    В 2018 году у нас произошёл 51 критический инцидент, а критичные элементы системы не работали в сумме больше 20 часов. В деньгах это 25 млн. рублей прямых потерь из-за несозданных и недоставленных заказов. А сколько мы потеряли на доверии сотрудников, клиентов и франчайзи, — подсчитать невозможно, в деньгах это не оценивается.

    Расходы на поддержку текущей инфраструктуры. При этом компания поставила перед нами цель на 2018 год: в 3 раза уменьшить стоимость инфраструктуры в пересчёте на одну пиццерию. Но ни программисты, ни DevOps-инженеры в рамках своих команд не могли даже приблизиться к решению этой задачи. Этому есть причины:

    • с одной стороны, для решения таких задач нужны программисты с глубокими знаниями инфраструктуры;
    • с другой стороны, нужны operations (назовём их баззвордом DevOps), которые умеют программировать на хорошем промышленном уровне;
    • с третьей стороны, бизнесу нужен баланс между надёжностью и доступностью этих систем и их стоимостью.

    И что с этим делать?


    Как решить все эти проблемы? Решение мы нашли в книге «Site Reliability Engineering» от Google. Когда прочли, поняли — это то, что нам нужно.

    Но есть нюанс — чтобы всё это внедрить нужны годы, и с чего-то надо начинать. Рассмотрим исходные данные, которые у нас были изначально.

    Вся наша инфраструктура почти полностью живет в Microsoft Azure. Есть несколько независимых кластеров для прода, которые разнесены по разным континентам: Европа, Америка и Китай. Есть нагрузочные стенды, которые повторяют продакшн, но живут в изолированной среде, а также десятки DEV-окружений для команд разработчиков.

    Из хороших практик SRE у нас уже были:

    • механизмы мониторинга приложений и инфраструктуры (спойлер: это мы в 2018 думали, что они хорошие, а сейчас уже всё переписали);
    • процессы для дежурств 24/7 on-call;
    • практика ведения постмортемов по инцидентам и их анализ;
    • нагрузочное тестирование;
    • CI/CD-пайплайны для прикладного софта;
    • хорошие программисты, которые пишут хороший код;
    • евангелист SRE в команде инфраструктуры.

    Но были и проблемы, которые хотелось решить в первую очередь:

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

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

    «Есть программисты, а есть инженеры инфраструктуры». Несмотря на то, что у нас достаточно хорошо была развита культура DevOps, всё ещё было это разделение. Два класса людей с абсолютно разным опытом, которые говорят на разных языках и пользуются разными инструментами. Они, конечно, дружат и общаются, но часто не понимают друг друга из-за совершенно разного опыта.

    Онбординг SRE-команды


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

    На проект мы выделили 4 месяца и поставили три цели:

    1. Обучить программистов тем знаниям и навыкам, которые необходимы для дежурств и операционной деятельности в команде инфраструктуры.
    2. Написать IaC — описание всей инфраструктуры в коде. Причём это должен быть полноценный программный продукт с CI/CD, тестами.
    3. Пересоздать всю нашу инфраструктуру из этого кода и забыть про ручное накликивание виртуалок мышкой в Azure.

    Состав участников: 9 человек, 6 из них из команды разработки, 3 из инфраструктуры. На 4 месяца они должны были уйти из обычной работы и погрузиться в обозначенные задачи. Чтобы поддерживать «жизнь» в бизнесе, ещё 3 человека из инфраструктуры остались дежурить, заниматься операционкой и прикрывать тылы. В итоге проект заметно растянулся и занял больше пяти месяцев (с мая по октябрь 2019-го года).

    Две составляющие онбординга: обучение и практика


    Онбординг состоял из двух частей: обучения и работы над инфраструктурой в коде.

    Обучение. На обучение выделялось минимум 3 часа в день:

    • на чтение статей и книг из списка литературы: Linux, сети, SRE;
    • на лекции по конкретным инструментам и технологиям;
    • на клубы по технологиям, например, по Linux, где мы разбирали сложные случаи и кейсы.

    Ещё один инструмент обучения — внутреннее демо. Это еженедельная встреча, на которой каждый (кому есть, что сказать) за 10 минут рассказывал о технологии или концепции, которую он внедрил в нашем коде за неделю. Например, Вася поменял пайплайн работы с Terraform-модулями, а Петя переписал сборку образов на Packer.

    После демо мы заводили обсуждения под каждой темой в Slack, где заинтересованные участники могли асинхронно обсуждать всё детальнее. Так мы избегали длинных встреч на 10 человек, но при этом все в команде хорошо понимали, что происходит с нашей инфраструктурой и куда мы катимся.



    Практика. Вторая часть онбординга — создание/описание инфраструктуры в коде. Эту часть разделили на несколько этапов.



    Реверс–инжиниринг инфраструктуры. Это первый этап, на котором разобрали, что где задеплоено, как что работает, где какие сервисы работают, где какие машины и их размеры. Всё полностью задокументировали.

    Концепты. Мы экспериментировали с разными технологиями, языками, подходами, выясняли, как можем описать нашу инфраструктуру, какие инструменты стоит для этого использовать.

    Написание кода. Сюда входило само написание кода, создание CI/CD-пайплайнов, тестов и построение процессов вокруг всего этого. Мы написали код, который описывал и умел создавать с нуля нашу дев-инфраструктуру.

    Пересоздание стендов для нагрузочного тестирования и продакшена. Это четвёртый этап, который должен был идти после онбординга, но его пока отложили, так как профита от него, как ни странно, гораздо меньше, чем от дев-окружений, которые создаются/пересоздаются очень часто.

    Вместо этого мы переключились на проектную деятельность: разбились на небольшие подкоманды и занялись теми глобальными инфраструктурными проектами, до которых раньше не доходили руки. Ну и конечно включились в дежурства.

    Наши инструменты для IaC
    • Terraform для описания текущей инфраструктуры.
    • Packer и Ansible для создания образов виртуальных машин.
    • Jsonnet и Python как основные языки разработки.
    • Облако Azure, потому что у нас там хостинг.
    • VS Code — IDE, для которой создали единые настройки, расширенный набор плагинов, линтеров и прочего, чтобы писать унифицированный код и расшарили их между всеми разработчиками.
    • Практики разработки — одна из основных вещей, ради которой затевался весь этот карнавал.


    Практики Extreme Programming в инфраструктуре


    Главное, что мы, как программисты, принесли с собой — это практики Extreme Programming, которые используем в работе. XP — гибкая методология разработки ПО, соединяющая в себе выжимку из лучших подходов, практик и ценностей разработки.

    Нет ни одного программиста, который бы не использовал хотя бы несколько из практик Extreme Programming, даже если он об этом не знает. При этом в мире инфраструктуры данные практики обходят стороной, несмотря на то, что они в очень большой степени пересекаются с практиками из Google SRE.

    О том, как мы адаптировали XP для инфраструктуры, есть отдельная статья. Но если вкратце: практики XP работают и для кода инфраструктуры, пусть с ограничениями, адаптациями, но работают. Если хотите их применять у себя, зовите людей с опытом применения этих практик. Большинство из этих практик так или иначе описаны в той самой книге о SRE.

    Всё могло бы сложиться хорошо, но так не бывает.

    Технические и антропогенные проблемы на пути


    В рамках проекта было два вида проблем:

    • Технические: ограничения «железного» мира, недостаток знаний и сырые инструменты, которыми приходилось пользоваться, потому что других нет. Это привычные любому программисту проблемы.
    • Человеческие: взаимодействие людей в команде. Общение, принятие решений, обучение. С этим было хуже, поэтому нужно остановиться подробнее.

    Мы начали развивать команду онбординга так, как стали бы делать это с любой другой командой программистов. Мы ожидали, что будут обычные стадии формирования команды по Такману: шторминг, норминг, а в конце мы выйдем на производительность и продуктивную работу. Поэтому не переживали, что вначале возникали какие-то сложности в общении, принятии решений, сложности с тем, чтобы договориться.

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

    • Опытные программисты с годами опыта, за которые они выработали свои подходы, привычки и ценности в работе.
    • Другая группа из мира инфраструктуры со своим опытом. У них другие шишки, другие привычки, и они тоже считают, что знают как правильно жить.

    Произошло столкновение двух взглядов на жизнь в одной команде. Мы не увидели этого сразу и не начали с этим работать, в результате чего потеряли очень много времени, сил и нервов.

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

    Если хотите собрать именно такую команду, не забудьте позвать сильного Agile- коуча, scrum-мастера, или психотерапевта — что больше нравится. Возможно, они помогут.

    Итоги онбординга


    По итогам проекта онбординга (он завершился в октябре 2019 года) мы:

    • Создали полноценный программный продукт, который управляет нашей DEV-инфраструктурой, с собственным CI-пайплайном, с тестами и прочими атрибутами качественного программного продукта.
    • Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE. Теперь они могут потушить пожар на проде, проконсультировать команду программистов по НФТ, или написать свою библиотеку для разработчиков.
    • Сместили майндсет в сторону идей SRE. Не только у участников проекта онбординга, но и у тех программистов из продуктовых команд, которые теперь могут разговаривать с нами на одном языке.
    • Сильно устали: и те, кто участвовал в онбординге, и те, кто участвовал в дежурствах.

    Вместо выводов: инсайты, не наступайте на наши грабли


    Несколько инсайтов от разработчика. Не наступайте на наши грабли, сэкономьте себе и окружающим нервы и время.

    Инфраструктура пока в прошлом. Когда я учился на первом курсе (15 лет назад) и начинал изучать JavaScript, у меня из инструментов были NotePad ++ и Firebug для отладки. C этими инструментами уже тогда нужно было делать какие-то сложные и красивые вещи.

    Примерно так же я ощущаю себя сейчас, когда работаю с инфраструктурой. Текущие инструменты только формируются, многие из них ещё не вышли в релиз и имеют версию 0.12 (привет, Terraform), а у многих регулярно ломается обратная совместимость с предыдущими версиями.

    Для меня, как энтерпрайз-разработчика, использовать на проде такие вещи – абсурд. Но других просто нет.

    Читайте документацию. Как программист, я относительно редко обращался к докам. Я достаточно глубоко знал свои инструменты: любимый язык программирования, любимый фреймворк и БД. Все дополнительные инструменты, например, библиотеки, обычно написаны на том же языке, а значит всегда можно посмотреть в исходники. IDE всегда подскажет, какие и где нужны параметры. Даже если я ошибусь, то быстро это пойму, запустив быстрые тесты.

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

    Комментарии в коде инфраструктуры неизбежны. В мире разработки комментарии — признак плохого кода. Они быстро устаревают и начинают врать. Это признак того, что разработчик не смог иначе выразить свои мысли. При работе с инфраструктурой комментарии так же признак плохого кода, но без них уже не обойтись. Для разрозненных инструментов, которые слабо связаны друг с другом и ничего не знают друг о друге, без комментариев не обойтись.

    Часто под кодом скрываются обычные конфиги и DSL. При этом вся логика происходит где-то глубже, куда нет доступа. Это сильно меняет подход к коду, тестированию и работе с ним.

    Не бойтесь пускать разработчиков в инфраструктуру. Они могут привнести полезные (и свежие) практики и подходы из мира разработки ПО. Пользуйтесь практиками и подходами от Google, описанными в книге про SRE, получайте пользу и будьте счастливы.

    PS: Я специально не стал затрагивать в этой статье темы микросервисов, Кубернетеса и прочие хайповые вещи, с которыми приходится учиться жить, так как это большая тема для отдельной статьи.

    PPS: Эта статья написана по моему выступлению на DevOpsConf осенью 2019 года. С тех пор прошло довольно много времени, и теперь уже точно понятно, что всё было не зря: тойл теперь не съедает бОльшую часть времени инженеров, наша команда теперь может реализовывать крупные долгосрочные проекты по улучшению инфраструктуры в широком смысле, а программисты почти не жалуются на безумных DevOps-инженеров, которые только мешают жить.

    PPPS: В этом году конференция, посвящённая DevOps-практикам, будет называться DevOps Live 2020. Изменения коснутся не только названия: в программе будет меньше докладов и больше интерактивных обсуждений, мастер-классов и воркшопов. Рецепты о том, как расти и перестраивать процессы с помощью DevOps-практик. Формат также изменится — два блока по два дня и «домашние задания» между ними.

    Чтобы узнать подробнее о том, что будет происходить на DevOps Live и что полезного вынесут инженеры, безопасники, тимлиды и CTO, подписывайтесь на рассылку и следите за публикациями в блоге.
    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 42

      +2
      В мире разработки комментарии — признак плохого кода

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

        0
        Если это ограничение техническое и кроется в сторонней системе, а ты пишешь какой-нибудь баш-скрипт (что очень часто встречается как раз в мире инфраструктуры или каких-то низкоуровневых языках/доменах), то да, комментарий здесь будет полезен. Хотя даже тут он рано или поздно устареет, но все последующие поколения разработчиков об этом не узнают.
        А вот если ограничение бизнесовое, а пишешь ты на полноценном ЯП, то комментарий тут скорее вреден: гораздо правильнее написать понятный тест, описывающий человеческим DSL'ем конкретный бизнесовый сценарий. И когда это ограничение поменяется, то вместе с ним разработчик будет вынужден поменять и тест, объясняющий зачем это здесь.

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

          я рассуждаю с точки зрения разработчика, а не админа.


          Хотя даже тут он рано или поздно устареет, но все последующие поколения разработчиков об этом не узнают.

          тесты тут не помогут, т.к. если Вы правильно заметили, что ограничение снаружи, то оно просто так не исчезнет. И тест попросту проверяет ограничение, а не говорит почему оно есть.
          ОКей, ограничение может быть описано в технической документации, но она деградирует еще быстрее, чем комментарии в коде.
          Например, вот объясните наличие этого ограничения без комментария.


          Еще вариант, когда комментарий помогает — это docstrings. Или комментарий к хитрому коду на С/C++, который реально когнитивно сложен и делает какую-то магию (например, 0x5f3759df — знаете, что это за константа и зачем она?)


          Поэтому говорить, что комментарии есть только в инфраструктурном коде или не нужны в обычном коде (ruby? python?) — это ложный аргумент.

            +5
            Не нужно возводить все в абсолют.
            Ограничение внешней системы можно и прокомментировать, только в случае с прикладным кодом таких систем и таких ограничений относительно мало, а в случае с инфраструктурным — на каждом шагу.
            Хотя в примере с OpenShift я бы просто вынес «24» в константу с именем OpenShiftMaxNameLength и не потерял бы ничего. Магические константы это еще один code smell наравне с повсеместными комментариями.
              +1
              Верно, таких констант и в мире физики и математики достаточно (Pi, e, h и т.д.). При знакомстве с системой я задаю вопрос знающим людям — как эта константа была выбрана. Как альтернативу — таком случае неплохо бы референс (ссылку на ресурс с описанием) или пояснение в комменте иметь — в быстро меняющемся мире софта и железа и константы могут устаревать.
              А комменты в коде обычно аргументируются: «мне не нравятся когда много методов и длинные имена у методов и переменных/констант», то есть личные предпочтения превышают общие/командные интересы.
                +2

                А тут надо принимать командные/проектные/корпоративные соглашения и стайлгайды и, увы, расставаться с теми, кто не хочет на них переходить, если такую вкусовщину считаете недопустимо в кодовой базе

                  0

                  Да, иначе это не работает.

                0
                Не нужно возводить все в абсолют.

                согласен, просто обе позиции (мы никогда не пишем комментарии и мы всегда пишем комментарии) — они пахнут максимализмом и… неверны. Как всегда — правильно — срединный путь ) смотреть по обстановке и целесообразности


                Хотя в примере с OpenShift я бы просто вынес «24» в константу с именем OpenShiftMaxNameLength и не потерял бы ничего

                это не помогло бы — в следующей версии OpenShift уже такого ограничения нет ) А указывать конкретную версию в названии переменной, ну, то же себе такое. Как известно, одна из фундаментальных проблем программирования — как декомпозировать объекты сущности (это к вопросу о монолит vs микросервисы) и как называть переменные сущности.

                  +1

                  А в комментарии указывать нормально версию?

          0

          Хм, у меня мультиклауд и я счастлив. Сидели на одном Azure — мы пару потеряли много денег, сразу все поняли и завели AWS.
          Сейчас 85% в Амазоне, 15% в ажуре.

            +1

            Точно, АЖУР НЕ НУЖЕН (С) 11111!!!!!!


            p.s. я именно с технической точки зрения — они еще долго будут в позиции догоняющих по отношению к Amazon & GC.

              0

              По отношению к AWS — да, но где они GC-то догоняют? GC мечтает сам их догнать…

              +1
              И при этом вы можете легко переключить весь трафик только на Ажур или только на AWS если у второго облака что-то сломается? Или в разных облаках просто разные части системы?
              По моему опыту, если хочется получать максимум пользы от облачной инфраструктуры и при этом не платить за это космические деньги, то ты вынужден использовать специфичные для конкретного облака сервисы и писать заточенный специально под них код.
              Это касается и прикладного софта (мы используем CosmosDB, Kusto, менеджед MySQL базы), так и инфраструктурного: например когда мы брали в стек тот же Terraform, то мечтали абстрагироваться от облачного провайдера, но по факту это конечно не так — для развертывания той же инфраструктуры в другом облаке придется очень много переписывать.
                0

                Да, можем. Не все конечно, есть очень специфичные приложение в Австралии, но это единицы. Тут конечно много особенностей и деталей плюс у меня своя специфика — регуляторка разных стран.

                  +1
                  Было бы очень интересно почитать, как это организовано — мы тоже рано или поздно придем к другим облакам. Но и собирать логи и прочую аналитику в условный Эластик после Azure Data Explorer уже кажется крайне плохой идеей)
                    0
                    Надо подумать о том, чтобы поделиться. Но нужно делать это конструктивно, а у меня сейчас только одни эмоции кипят про Azure.
                    MatveyGrigorev — Вы попадали на hardlimit в Azure? Когда просто терминируется BGP сессия и весь регион не доступен :)
                      0
                      Насколько я помню, мы вляпывались только в лимиты по Resource Manager API, но это не фатально.
                      По остальным вроде пока все ОК, по необходимости договариваемся с Ажуром и хватает одной подписки.
              +1
              команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение


              Это как так то?
                +1
                Легко)
                Само приложение и бекенд к нему выкатывается задолго до публичного анонса: распространяется на небольшую группу лояльных бета-пользователей и постепенно дорабатывается. А в какой-то момент бизнес принимает решение что все ОК – и публикует пост в соцсетях с призывом скачать приложение и получить пиццу в подарок за первый заказ. Profit.

                Это сейчас мы все умные и синхронизируем все маркетинговые активности со всеми причастными техническими командами, оцениваем нагрузку и т.п., а тогда, увы, этого не было. Плюс никто не ожидал такого наплыва пользователей именно в приложение: никому и в голову не могло прийти что через несколько месяцев оно станет популярнее сайта.
                +3
                На время разработки на продакшене был развёрнут один слабый сервер. Перед публичным анонсом приложения его нужно было увеличить.

                команда инфраструктуры даже не знала, что сегодня релизится какое-то приложение.


                Тогда я вывел для себя очевидное, но важное правило: Если хочешь, чтобы твоё приложение жило долго и счастливо, внимательно следи за тем, где и как оно выполняется на проде. Даже если для этого есть специально обученные люди.


                Не хочу вас расстраивать, но вы сделали неправильный вывод. У вас в компании проблемы с бизнес процессами и планированием. Релиз приложения\информационной системы — это не случайно событие, а запланированное, поэтому все заранее осведомлены о его сроках. О релизе всегда знает технический сектор (dev и ops), бизнес сектор с владельцами компании, а также отделы маркетинга и PR.

                Они решили, что следить за продакшеном «некритичного» сервиса — обязанность команды приложения. А разработчик бэкенда решил, что в крупных компаниях этим занимаются ребята из инфраструктуры.


                Чтобы ops могли поддерживать то, что dev накодили, эти dev должны официально передать систему\сервис коллегам из ops, снабдив всё это необходимой для ops документацией с описанием компонентов и принципов работы. До момента официальной передачи всё, что накодили dev принадлежит dev и поддерживается силами dev.

                  0

                  При некоторых процессах релиз можно отнести к случайным событиям. Как прлдакт оунер говорит, что фича готова, так и релизим с какой-то CD. А то и просто галочку ставим в панели управления фичами. Процессы они разные бывают.

                  +2
                  Инфраструктура пока в прошлом

                  Очень интересно рассказывать об этом из мира, в котором состояние не является проблемой программиста. Надо хранить данные в таблицах? Отлично, берём учетные данные в СУБД и пишем/читаем, пока не сдохнет. Когда сдохнет — жалуемся DBA, они там задаром, что ли, деньги получают. Надо узнать, по какому IP-адресу находится сервис? Отлично, берём DNS и спрашиваем, пока не сдохнет. Когда сдохнет — жалуемся админам, 1000 вопросов в секунду «где example.com» это даже не хайлоад.


                  Инфраструктура, тем временем, сделана из состояния почти целиком. И возникает следующий отличный диалог между dev и ops:


                  Dev: инфраструктуру надо чинить, инфраструктуру.
                  Ops: на, сам делай!
                  Dev: мне нельзя, я чатланин фичи пилю.


                  Вот и появляются отделы DevOps/SRE и прочая ИБД.


                  У вас же, говорят, принято людей из компании в пиццерию отправлять для ознакомления? Вот отправляйте ещё разработчиков в on-call. Они даже могут ничего не делать руками на проде, просто поднимайте их по любой тревоге, и давайте какую-нибудь несложную обязанность типа внешней связи с пострадавшими и составления короткого отчета об инциденте с их точки зрения.

                    0

                    "мы живем в Azure"
                    Прям туда персональные данные отъезжают?))

                      +2
                      Спасибо, прочитал с интересом, но одно высказывание меня конкретно смутило:
                      Удвоили количество людей, которые готовы дежурить и сняли нагрузку с текущей команды. Спустя ещё полгода эти люди стали полноценными SRE.

                      Полноценным SRE не стать за полгода, слишком большой домен знаний. И даже за полтора это сделать очень сложно.
                      Особенность SRE — это большой домен знаний и очень сильные навыки дебага и пожаротушения вкупе со скилами архитектора. Ну кроме остальных навыков, конечно.
                      Причём, если более менее сносный код можно научиться писать за эти полтора года, то архитектурные и эксплуатационные скилы развить за это время с ноля можно разве что до уровня «уверенный джун», потому что, как вы очень правильно сказали, в эксплуатации очень много всего, а уж в архитектуре и подавно.
                      В целом, я могу допустить, что за это время можно дорасти до «SRE конкретного окружения конкретной компании», но потом придётся двигаться и развиваться дальше и несоответствие будет всплывать все чаще и чаще (вот хотя бы история мультиклауда наглядный тому пример).
                      Так или иначе, удачи вашей команде, это все интересно :)
                      P.S. Мне довелось поработать с SRE из гугла на протяжении почти года достаточно плотно и к сожалению у меня сложилось впечатление, что они сами не в полной мере соответствуют тому, о чем пишут в собственной книге. Что конечно не исключает существования других команд, где на самом деле есть полноценные SRE которые могут качественно делать все, что предполагается им по роли.
                        +1
                        Мне довелось поработать с SRE из гугла на протяжении почти года достаточно плотно и к сожалению у меня сложилось впечатление, что они сами не в полной мере соответствуют тому, о чем пишут в собственной книге. Что конечно не исключает существования других команд, где на самом деле есть полноценные SRE которые могут качественно делать все, что предполагается им по роли.

                        Плюсую бешено, но гугл, как один из основных работодателей и одна из инфра-образующих компаний, может себе позволить многое — в том числе и создавать прослойку SRE.
                        А еще очень интересно поговорить за топологию команд. Вот, ня

                          +1
                          Полностью согласен, погорячился.
                          Идея была в том, что мы получили от новой команды то, что ожидали — и это круто.
                          При этом у меня лично возникла другая проблема: с одной стороны за суммарно полтора года я капитально растерял навыки работы в привычной среде .NETа, а с другой стороны стал «SRE конкретного окружения конкретной компании» и понимаю что мне еще расти и расти. И это вызывает серьезный психологический дискомфорт.
                            +1
                            И это вызывает серьезный психологический дискомфорт.

                            Решайте его скорее и генерализируйте компетенции, иначе рискуете очень надолго застрять в этой каше и впоследствии огрести много карьерных проблем. Сейчас у вас судя по всему самое время качаться в эту сторону, расширять стек и становиться очень востребованным Azure DevOps/SRE, по крайней мере.
                          +1

                          А какая мотивация у разработчиков уходить в "админство"? Я долгое время не могу такими вещами заниматься, полгода, наверное, и выгорать начинаю без реальных фич, которые делаю для пользователей. Причём серьёзных, а не "на отвлекись, перекрась кнопку и поле добавь"

                            +1
                            За всех не скажу, но в моем случае это было ощущение того что «здесь я неплохо понимаю и умею, пилить фичи уже скучно, да и без меня полно народу — справятся» и «там у этих ребят Дикий Запад, все в огне, есть где развернуться». Мне нравится заниматься проблемами, решение которых потенциально может принести огромный профит.
                            А «админскую» часть здесь я воспринимаю скорее как неизбежное зло для того чтобы получить знания, необходимые для нанесения непоправимой пользы окружающим. Хотя конечно иногда возникают мысли «зачем я в это все вляпался?»)
                              0

                              Ну вот меня мотивирует туда лезть желание обеспечить прежде всего себе комфортную среду для разработки :) То есть настроил раз и дальше только поддерживать...

                              +1
                              Полный цикл разработки.
                              Если выкинуть модное слово SRE и немного вернуться и поговорить о DevOps подходе (а не человеке), то фактически DevOps — это настойщий полный фул-стек.
                              С одной стороны — делается продукт, с другой — этот продукт с помощью определенных инструментов катится в прод к клиенту и обратная связь появляется маскимально быстро, модификации идут более точно т.к. часть можно решить инфрой, часть — через изменения продукта и т.д.
                              Мотивация этого действа полностью бизнесовая. А базовая необходимость в том, что современная инфрастуктура может быть на порядки сложнее большинства приложений, что на ней работают и без общего понимания всего хотя бы на среднем уровне получаются плохо работающие приложения, велосипеды, перерасход ресурсов на поддержку и т.д.
                              А еще это интересно и хайпово просто:)
                              Короче одно другому не мешает, проблема только в том, что программистов, умеющих в девопс мало. Очень мало. Как и «девопсов» умеющих в архитектуру и программирование. И даже если их собрать в одной команде, придется еще и все процессы перестроить, а для этого надо очень хорошо знать что ты делаешь, что опять же проблема, потому что найти такого лида тоже сложно и т.д.
                              Поэтому часто идут перекосы и нормальный процесс превращается в то, что все занимаются не своим делом, но под новой вывеской.
                                0

                                Ну вот я такой фуллстэк, наверное, фичи делал некоторые в одно лицо от UI/UX и фронта на реакте до helm чартов (с попутной контрибуцией в апстрим), да ещё имея в виду, что то, что я сделаю станет неформальным образцом для всех команд как нужно у нас делать.


                                Интерсно, да. Но ведь речь идёт, как я понимаю, о полном отходе от разработки пользовательских фич. Вот такого я долго выношу.

                                  0
                                  речь идёт, как я понимаю, о полном отходе от разработки пользовательских фич.

                                  Это как раз то, чего в принципе быть не должно — тот самый перегиб. Сама идея как раз в том, чтобы и пилить фичи, и крутить их. По крайней мере в DevOps.
                                  В SRE действительно надо отказываться от пиления фич, но там свой интересный мир.
                                    0

                                    Сплошь и рядом отдельные девопс инженеры и целые девопс команды, не очень понятно чем отличающиеся от классических админов, которым ещё и задачу поддерживать CI/CD пайплайнв и прочие кубернетесы поставили. Да и большинство разработчиков в это лезть не горят желанием. А человек 10-15 разработчиков из которых ты один не против немного в этом покопаться, быстро прервщается, что ты становишься таким то ли девопсом, то ли SRE на фуллтайм

                                      0
                                      Все так. Вы только что озвучили совершенно классическую проблему, когда «давайте делать девопс, но без сильных изменений», из-за чего нифига не летит.
                                        0
                                        Сплошь и рядом отдельные девопс инженеры и целые девопс команды, не очень понятно чем отличающиеся от классических админов, которым ещё и задачу поддерживать CI/CD пайплайнв и прочие кубернетесы поставили.

                                        есть разница. Потому что то, о чем Вы говорите — это платформенные инженеры, который (внезапно!) пилят продукт — внутренний продукт — платформу, куда будут деплоиться приложения других, продуктовых команд. В чем же разница платформенной команды от продуктовых? В том, что продуктовые заточены на бизнес-фичи, а платформенная — именно на унификации процессов деплоя, мониторинга etc., обеспечении стабильности работы платформы и все прочее. Т.е. уже не админы, но еще и не 100% разработчики.

                                  +1

                                  Я вот пошел в SRE в Google именно из желания пощупать руками сотни миллионов QPS и как оно вообще может работать. Оказалось очень познавательно. И проблемы интересные решаются.


                                  При этом рядом сидит команда "разработчиков" этого же продукта, и даже не скажешь, у кого интереснее и "креативнее" что ли работа.

                                    0

                                    Для меня такой интерес был бы в принципе в Google пойти. Я вот именно про переход из разработчиков в SRE/DevOps без смены компании/продукта.

                                      0

                                      Приходите :)


                                      Google большой, и люди тут разными вещами занимаются, совсем не только высокими нагрузками. Но мне показалось интересным именно вот в гуще узнать, как это все реально работает. Как это чинят, как проектируют, что за люди, как оно работает. И тут SRE — самое оно.

                                        0

                                        Где Google и где я ) Хотя вот погуглил, оказывается в прошлом году в Киеве появился R&D центр Гугла, правда кроме новостей ничего не гуглится

                                          0

                                          Насчёт Киева не скажу, но в Варшаве большой центр разработки и активно набирают людей. Ещё Цюрих, Лондон, Дублин.

                                  0
                                  Недурно, но круг проблем и решений останется…

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое