Русский
Русский
English
Статистика
Реклама

Как перейти от кровавого энтерпрайза к командной работе

Сергей Минаев руководитель направления администрирования 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и присоединяйтесь к обсуждениям.

Источник: habr.com
К списку статей
Опубликовано: 01.12.2020 10:20:26
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании конференции олега бунина (онтико)

Devops

It-компании

Devops devoops доклад конференция

Конференция devoops

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru