.model tiny
.code
org 100h
start: mov ah,9
mov dx, offset message
int 21h
ret
message: db "Hello Habr!", 00h, 0Ah, '$'
end start
Меня зовут Сергей Минаев, я руководитель направления администрирования веб-сервисов в компании «Спортмастер». Моя группа занимается разворачиванием и поддержкой всего, что связано с вебом и мобилкой.
Большинство систем мы пишем сами, но в то же время мы иногда используем и коммерческий софт. В целом можно сказать, что мы стараемся работать «модно-молодежно»: у нас есть автоматизация на Ansible (именно автоматизация, а не деплой), у нас есть CI/CD на Bamboo + Bitbucket. Есть оркестрация на Mesos, от него мы постепенно переходим к Kubernetes.
Есть и заявки - это не только взаимодействие с другими отделами, но и взаимодействие разработки-эксплуатации. Поэтому мы смотрим в сторону GitOps.
Наши проблемы
Одна из самых тяжелых проблем - это взаимодействие на уровне “перекидывания через забор”: всё, я работу свою сделал, я закончил, а работает система или нет, это уже не так важно. Перестроить такое восприятие достаточно сложно, мы пытаемся исправлять ситуацию, но дается это нелегко.
Из предыдущего вытекает еще одна проблема — это подход «У меня локально все работает, если у коллег в деве/проде не запустилось — это их проблемы, пускай сами разбираются». Подобная проблема есть, наверное, практически у всех. Как мы стараемся ее решать: по максимуму переносить окружения на единую платформу, в нашем случае Kubernetes с динамическими окружениями.
Но только применением инструментов здесь дело не решить, необходимо проводить большую “социальную” работу. То есть сделать так, чтобы команды в целом понимали, что, если все работает локально – это не “готово”. Готово – это когда работает в общем окружении.
Еще одна вечная проблема - разность в окружениях. Да, можно сказать, что это наследство, но не стоит недооценивать и наши заслуги — желание что-то быстро запустить. Такие моменты нельзя решить чисто технологическим путем, надо перестраивать процессы и восприятие. Культивировать понимание, что сделанное наспех и с костылями обязательно необходимо в будущем отрефакторить.
Если этого не сделать, мы когда-нибудь обязательно выстрелим себе в обе ноги сжиганием времени на обнаружение багов. Да, полностью от костылей не уйти, но нужно стараться минимизировать ущерб.
А самое печальное из всего, с чем мы сталкиваемся, связано с откладыванием решения проблемы в долгий ящик. Продуктовая команда может внести изменения в свою платформу и не уведомить нас об этом. А потом постфактум обратиться за помощью с решением проблемы, о которой мы даже догадаться не сможем. Да, я счастлив, что в моей команде прекрасные инженеры и в принципе мы можем решить практически любые задачи. Но все же — лучше изменения обсуждать с командами, которые так или иначе связаны друг с другом.
И напоследок: взаимодействие со смежниками и инфраструктурой. Чтобы что-то решить, нужно заводить заявку. И если нет заявки, то нет и работы. На этом моменте много чего рушится. История с заявками в целом штука очень тяжелая, от нее сложно уйти, и полностью она не исчезнет, как бы мы ни старались с GitOps и владением инфраструктурным кодом продуктовыми командами.
DevOps — ожидание vs. реальность
В общем, все эти вещи очень мешают нам жить. И обычно в таких случаях предлагают решение — DevOps, который быстро, качественно и надежно всем поможет, и будем мы жить довольно и счастливо. Примерно такое представление сложилось на рынке в целом. Минимум усилий, минимум времени, все само рассосется, главное — наймите DevOps’ов.
Но когда доходит до практики и DevOps вроде бы “появляется”, обычно все получается не так, как ожидалось. Потому что обычно DevOps воспринимается как системный администратор, который умеет и админить, и программировать, и еще много чего за одну зарплату. И в лучшем случае, продуктовая команда не теряет в производительности и качестве, но обычно теряют во всем.
Как же мы видим DevOps? Для нас это и командная работа с подключением инженера эксплуатации (админа), и процесс, и методология, и философия. И главное здесь — донести все до людей. Договориться, объяснить, проговорить что изменится и что нет, и только потом подключать инженера. Просто прийти и сказать: «Вы теперь работаете по DevOps» - этого мало. Инженер к команде не просто подключается, приходит и решает все задачи. Если работать по этому сценарию, инженер просто выгорит, а у нас все останется, как было (в лучшем случае). Все вопросы должны решаться совместно.
Помимо просто теории, процессов, необходимо понимать, что вообще происходит. То есть вводить метрики. Стандартные — это время выкаток и их количество. Есть мнение, что чем их больше, тем лучше, но я с ним не согласен. Не нужно забывать про качество. Согласитесь, что выкатить что-то, а потом откатиться, или выкатить, а затем выдать фикс — это не одно и то же. Я считаю, что выкатка должна быть наиболее стабильной и качественной, но этого не всегда можно добиться. И это нормально. Не все дается с первого раза, второго…
Мы хотим сделать так, чтобы все было надежно, безопасно и воспроизводимо. Мы всегда можем повторить то, что мы делали, и если что-то пошло не так, мы можем достаточно спокойно откатиться. Изменение не может произойти без быстрой обратной связи, общих каналов и обмена опытом. Нельзя просто позвать инженера работать в продуктовую команду с определенным списком технологий. Он помогает и обучает команду, которая должна понимать хоть какой-то базис о специфике его работы. А инженер должен хоть немного понимать специфику продуктовой команды.
Мы понимаем, что наш подход — не панацея, и что угодно может пойти не так. Главное помнить о том, что любую проблему или просто задачу нужно решать совместно.
Инструменты и социальность
Мы сталкиваемся с тем, что продуктовая команда выбирает себе инструменты сама, и в этом вроде бы нет ничего плохого. Но плохо то, что об этом выборе никто за пределами команды не знает. И если вдруг что-то случится, может оказаться так, что помочь трудно.
Вы не можете просто поставить Kubernetes и сказать всем — ура, у нас Kubernetes, работаем. Это не просто софт, это платформа, вопрос экосистемы, деплоев. Kubernetes добавляет много вопросов, на которые не всегда можно быстро ответить.
Инструменты — это базис, фундамент, должен быть единый технологический стек. Но должна оставаться возможность этот стек пересматривать.
Самоорганизация. Все знают, что это модно, работает и вообще здорово. Но это обоюдоострый подход. Забастовка, по сути, это тоже своего рода самоорганизация. Надо обговаривать правила игры, чтобы каждый сотрудник понимал, что и как работает, чтобы все знали границы. Если этого не сделать, команда может закрыться от подключаемых инженеров и пытаться делать все своими силами. В итоге, возможно, двигаться ничего не будет.
Автоматизация. Идеальный способ что-то испортить в процессе работы - это абсолютно бездумно что-то применять в работе и, более того, навязывать это остальным. С автоматизацией главное не перестараться, надо понимать, что и зачем, когда и для чего. Например, деплой при помощи Ansible — чаще всего не очень хорошее решение
Гибкость. Нужна во всем, DevOps не может быть гибким только с одной стороны. Если так работают только инженеры/команды, а бухгалтерия не может, то получится, что команды будут ждать новых серверов долгое время. И таких историй множество.
Облака. Сейчас мы все активнее их используем, особенно для каких-то тестов и проверок гипотез. Например, есть у нас MVP — его проще развернуть в облаке в пару кликов, чем ждать выделения локальных ресурсов.
Знания. Внутри команд надо обязательно делиться знаниями и обсуждать их актуальность. Болевой точкой тут может быть так называемый “сотрудник-дракон”, который в силу опыта или амбиций уверен, что тут только он прав и он один знает, как правильно. Мы стараемся распространять знания и доносить до всех, что мир меняется, любые парадигмы надо пересматривать.
Команда. Часто забывают про то, что все сотрудники ценны, и игнорируют тот факт, что сотрудники в целом — это система. А тут критичное значение имеет то, как именно эти сотрудники взаимодействуют между собой, как общаются, как принимают решения, как договариваются. Убрав одного человека из команды или заменив его, можно потерять ценность — вся команда станет работать иначе.
Что и зачем. Самые важные вопросы, которые всегда надо задавать, когда что-то делаешь, если вы хотите видеть результат. Без понимания этих вещей у вас не будет прозрачности, а реальность будет расходиться с ожиданиями.
Выводы
В первую очередь — люди. Какими бы ни были ваши инструменты, процессы и лозунги, без людей и их совместной работы ничего не получится. Автоматизация спасает и уменьшает рутину, но к ней надо подходить аккуратно, чтобы не увеличить число проблем. Инструменты необходимо подбирать осознанно.
DevOps - это работа, большая работа. Нужно смотреть на методологии, подходы, выбирать то, что применимо именно к вашей ситуации, а не просто взять что-то и пытаться использовать. Да, это, скорее всего, будет дорого, но в перспективе это даст плюсы. Мы понимаем, что командам помогает такая трансформация, да и бизнесу тоже. DevOps не всегда нужен, и, занявшись его внедрением, можно сделать хуже. Это обычно заметно, если команда маленькая или не готова. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.
