.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 не всегда нужен, и, занявшись его внедрением, можно сделать хуже. Это обычно заметно, если команда маленькая или не готова. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.
