Сергей Минаев — руководитель направления администрирования Sportmaster Lab. Занимается поддержкой окружений и всем, что связано с работой кода. Он участвует в IT-трансформации компании, и в своем докладе на конференции «DevOps Live 2020» рассказал о том, как это происходит.

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

Стараемся применять современный подход: у нас есть автоматизация, мы понимаем где и когда использовать Ansible. Есть CI/CD на Bamboo и BitBucket. Есть оркестрация на основе Mesos, но мы двигаемся в сторону Kubernetes  (и поглядываем на GitOps).

Наши проблемы

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

Из предыдущего вытекает еще одна проблема: подход «у меня локально все работает, если у них не работает — это не моя проблема, разбирайтесь сами».

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

В том числе речь идет и о наследстве, но в процессе работы мы и сами, желая что-то быстро запустить, получаем костыли. Такие моменты нельзя решить чисто технологическим путем, необходимо перестраивать восприятие. Создавать понимание, что сделанное наспех и с костылями в будущем нужно привести к нормальному виду и отработать техдолг. Если этого не сделать, мы когда-нибудь выстрелим себе в обе ноги из-за сжигания времени на обнаружение багов.

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

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

Не забываем и про работу со смежными подразделениями: чтобы что-то решить, нужно заводить заявку. Нет заявки — нет и работы. Работа по заявкам — штука очень тяжелая, от нее сложно уйти, и полностью она не исчезнет, как бы мы ни прикладывали усилия с GitOps и владением инфраструктурным кодом продуктовыми командами.

DevOps: ожидания vs реальность

Все это мешает быстро двигаться дальше. И обычно в таких случаях предлагают решение — DevOps, который быстро, качественно и надежно всем поможет. Примерно такое представление сложилось на рынке, в целом. Минимум усилий, минимум времени, главное — наймите DevOps’ов.

Но на деле выходит иначе.

Что такое DevOps, и для чего он нужен обычно не объясняют. DevOps воспринимается как системный администратор, который умеет и админить, и программировать, и еще много что делать. Причем, за одну зарплату. И в лучшем случае продуктовая команда не теряет в производительности и качестве.

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

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

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

Кроме того, изменения невозможны без быстрой связи, без общих каналов и без обмена опытом. Нельзя просто сказать: «Ты, Ваня, приходи в команду, помогай с такими-то технологиями». Это так не работает. Инженер не приходит мыть полы и менять картриджи. Он обучает команду и помогает ей. И люди в команде должны понимать, что и почему он делает. Но и инженеру нужно знать и понимать для чего он тратит свои силы. 

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

Как внедрять DevOps?

Нужно не забывать о том, что DevOps —  дело добровольное,  его нельзя навязать. 

Если продуктовая команда выбирает себе инструменты сама, в этом вроде бы нет ничего плохого. Но о выборе подходящих инструментов должно быть известно за ее пределами. Вы не можете просто поставить Kubernetes и сказать всем — ура, у нас Kubernetes, работаем. Это не просто софт, это платформа, вопрос экосистемы, деплоев. Kubernetes добавляет много вопросов, на которые не всегда можно быстро ответить.

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

Самоорганизация. Все знают, что она работает здорово. Но не стоит забывать, что забастовка — тоже своего рода самоорганизация. Надо обговаривать правила игры, чтобы каждый сотрудник понимал что и как работает, и чтобы все знали границы. 

Автоматизация. Идеальный способ что-то испортить в процессе работы — абсолютно бездумно что-то применять, и навязывать это остальным. С автоматизацией главное не перестараться, нужно понимать, когда и для чего она нужна. 

Гибкость. Нужна во всем. DevOps не может быть гибким только с одной стороны. Если так работают только инженеры/команды, а бухгалтерия не может, то получится, что команды будут ждать новых серверов долгое время.

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

Знания. Внутри команд надо обязательно делиться знаниями и обсуждать их актуальность. Болевой точкой тот может быть так называемый «сотрудник-дракон», который в силу опыта или амбиций уверен, что только он один знает, как правильно. 

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

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

Технологии и инструменты

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

Мы понимаем, что Kubernetes — это решение не во всем и не всегда. Kubernetes для нас — не просто платформа. Это целая экосистема. Можно сказать, что в какой-то степени речь идет о фреймворке.

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

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

Выводы

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

Автоматизация спасает и уменьшает рутину, но к ней надо подходить аккуратно, чтобы не увеличить число проблем. Инструменты стоит подбирать осознанно.

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

DevOps не всегда нужен, и занявшись его внедрением, можно сделать хуже. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.

Пока пандемия идет к завершению, продолжаем встречи онлайн.

3 декабря будет митап «Безопасность и надёжность в финтехе». Спикеров будет несколько, и они поднимут несколько тем. Сначала будет разговор о закулисье финтеха, затем — как и какими инструментами сделать финтех надежным сервисом, и на закуску — как снизить риски ИБ в разработке финансовых систем. Начнем в 17:00.

А 7 декабря в 16:00 вас ждет митап «Stateful-приложения в 2020 году». Поговорим о Stateful в 2020. Сейчас много всяких методологий, подходов и новых принципов работы. Но они больше ложатся на stateless. А что в это время происходит с БД? Как жить и поступать с ними сейчас, в 2020 году? И какие перспективы и тренды нас ждут?

Следите за новостями — Telegram, Twitter, VK и FB и присоединяйтесь к обсуждениям.