[Управление разработкой, Управление персоналом, DevOps] От кровавого энтерпрайза к командной работе
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
.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 не всегда нужен, и, занявшись его внедрением, можно сделать хуже. Это обычно заметно, если команда маленькая или не готова. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально.
===========
Источник:
habr.com
===========
Похожие новости:
- [Open source, Git, Виртуализация, Openshift] Red Hat Advanced Cluster Management и управление приложениями, часть 1. Развертывание в нескольких средах
- [Управление разработкой, Учебный процесс в IT, Управление персоналом, Карьера в IT-индустрии] Как не испортить своего джуна
- [Управление разработкой, Управление продуктом] Настроили мониторинг. Что дальше?
- [IT-инфраструктура, DevOps, Openshift] Все об OpenShift Egress. Часть 1
- [IT-инфраструктура, Сетевые технологии, DevOps] Сегодня, 12 ноября в 18 часов(MSK) состоится Online Monitoring Meetup
- [Системное администрирование, Серверное администрирование, Управление разработкой, DevOps] Приглашаем на митап «Apache Kafka в вопросах и ответах» 17 ноября в 19:00
- [Развитие стартапа, Управление персоналом, Карьера в IT-индустрии, IT-компании] 10 причин не идти в стартап
- [Open source, Git, Системы управления версиями, DevOps] Вышел релиз GitLab 13.5 с обновлениями для безопасности мобильных приложений и вики-страницами групп
- [Управление персоналом, Карьера в IT-индустрии, DevOps] DevOps для IT-рекрутеров
- [Управление разработкой, Управление проектами, Управление продуктом, Бизнес-модели, IT-компании] Как запустить IT-продукт за 1,5 месяца и не закрыться через полгода с колоссальными убытками
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (Управление персоналом), #_devops, #_devops, #_sportmaster (спортмастер), #_sportmaster_lab, #_upravlenie_razrabotkoj (управление разработкой), #_kubernetes, #_blog_kompanii_sportmaster_lab (
Блог компании Sportmaster Lab
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_upravlenie_personalom (
Управление персоналом
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:20
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
.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 не всегда нужен, и, занявшись его внедрением, можно сделать хуже. Это обычно заметно, если команда маленькая или не готова. Поэтому необходимо оценивать каждую команду и ситуацию индивидуально. =========== Источник: habr.com =========== Похожие новости:
Блог компании Sportmaster Lab ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_upravlenie_personalom ( Управление персоналом ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:20
Часовой пояс: UTC + 5