Привет, друзья. Без громких слов, приглашаем всех Dev, Ops и сочувствующих на @DevOps Meetup #2 — послушать:
- как Райффайзенбанк перешел от зоопарка инструментов CI/CD к централизованному конвейеру на базе стека Atlassian;
- о сложностях логирования и мониторинга от «Рунет Бизнес Систем» — вы узнаете, как сделать полезную и безопасную агрегацию в условиях динамической инфраструктуры;
- и напоследок выступит Росгосстрах с рассказом о лучших практиках своего DevOps’а.
Встреча пройдет 22 августа (четверг) в 18:30 в московском офисе Mail.ru Group (Ленинградский проспект, д. 39, стр. 79). Регистрация обязательна и закрывается 20 августа в 23:59 (или раньше, если закончатся места).
«Мы уйдем из зоопарка, или Как Райффайзенбанк перешел к CI/CD-конвейеру на базе Atlassian»
Константин Курочкин, Райффайзенбанк, руководитель группы автоматизации IT-процессов
Константин долгое время занимался внедрением и поддержкой инструментов автоматизации в Райффайзенбанке, а сейчас руководит группой автоматизации IT-процессов в составе команды по технической трансформации банка.
Докладчик расскажет, как от зоопарка инструментов CI/CD Райффайзенбанк перешел к централизованному конвейеру на базе стека Atlassian.
Как рождается зоопарк, никому объяснять не надо. Команды разработки используют совершенно разные языки программирования, фреймворки и инструменты. Команды поддержки тоже пользуются тем, чем умеют, с разной долей успешности. У нас у Dev были свои инструменты, у Ops — свои. Про автоматизацию сначала можно было говорить только с большой долей абстракции.
Следующий шаг — некоторые команды начинают активно выстраивать свой автоматизированный процесс. Что не могло не радовать, но их опыт было трудно масштабировать из-за количества используемых технологий и различий в них. Jenkins, TeamCity, Bamboo, Artifactory, Nexus — в общем, каждый делал, что хотел и как умел. Поддерживались все эти инструменты самими разработчиками, которые тратили на это часть своего времени вместо того, чтобы пилить новые фичи.
От первой ласточки в виде Jira — через централизацию всех систем хранения исходного кода — к полноценному конвейеру для автоматизации CI/CD. Да, на базе Bamboo. Вы узнаете, почему именно он и какие сложности были на пути. А также:
- что было в нашем зоопарке и как он образовался. Обзор инструментов, использовавшихся в командах, и проблемы, с ними связанные;
- Jira — первая ласточка централизации;
- нелегкий выбор инструментов и к чему мы пришли;
- как мы сами себе создали кучу проблем, или Почему команда автоматизации не умеет автоматизировать;
- облако не в облаке и не в штанах;
- зоопарк побежден — посмотрим, что получилось и как это работает;
- от Continuous Delivery до Continuous Deployment — один плагин;
- над чем мы сейчас работаем: DevSecOps, Kubernetes и PKS, мониторинг.
«Логирование и мониторинг. Полезная и безопасная агрегация в условиях динамической инфраструктуры»
Владимир Медин, «Рунет Бизнес Системы», DevOps-инженер
Логирование и мониторинг — практически не отделяемые сущности современной IT-платформы. Если мониторинг позволяет оценивать текущее состояние систем, заблаговременно предотвращать инциденты, проводить аналитику и выявлять корреляцию событий с возможностью восстановления их хронологии, то логирование дает специалистам разных структур агрегировать события, разбирать баги на верхнем уровне, проводить аудит безопасности и быстро закрывать задачи поддержки, не затрачивая ценное время на поиск этой информации и сбор картины из паззла.
Но на практике в большинстве случаев мы видим работающий мониторинг с нескончаемым потоком алертов непонятной природы и неизвестной ожидаемой реакцией. Специалисты по тестированию получают уведомления об изменении системных файлов конфигурации на Production-среде, а дежурные администраторы наблюдают уведомления о неполадках в тестовых средах.
Когда система агрегации логов выглядит как свалка сообщений из неизвестных источников с неизвестной важностью — поиск в таких условиях изнуряет и приводит к возврату использования grep на хостах. Побочная проблема агрегации логов — обработка чувствительных данных.
Докладчик, основываясь на своем опыте DevOps в компании, предоставляющей услуги в области электронной коммерции и процессинга электронных платежей, расскажет, как они справляются с потоком событий и как выстроили свою систему агрегации. Не забудем об отказоустойчивости систем, портов публикации, разделения федераций кластеров, а также о том, как автоматизировать сбор логов и метрик с новых хостов и Docker-контейнеров и автоматизировать качественно. В докладе будет освещено применение таких инструментов, как: Zabbix, Prometheus, cAdvisor, Node_Exporter, Logstash, Rsyslog, Graylog2, ELK Stack.
Вы узнаете:
- как построены наши системы агрегации логов и метрик;
- какие инструменты мы используем и в каких случаях;
- как мы автоматизировали процесс добавления новых элементов в системы;
- как мы централизовали обработку и фильтрацию сообщений при работе с чувствительными данными;
- как исключить флуд алертов и какой политики системы оповещений мы придерживаемся;
- как мы взаимодействуем с разработкой для определения вида логирования;
- что мы хотим улучшить и дальнейшие перспективы развития.
«DevOps. Как это делают в Росгосстрахе»
Александр Крылов, Росгосстрах, начальник службы DevOps
Эта история со счастливым концом — о том, как плохо было вести процесс апдейта трёх взаимозависящих систем до внедрения полного стека Atlassian и средств автоматизации c использованием Ansible — и как мы дошли до практик DevOps, которыми хочется делиться. Расскажем, чего достигли и какие есть планы на развитие.
Будут освещены системы расчётов и продаж полисов КАСКО/ОСАГО в Росгосстрахе и дополнительные интеграции.
При зарождении новых систем по продаже полисов автострахования — CI/CD как такового в Росгосстрахе не было. Это был далекий 2016 год, когда у системы полисов была всего одна нода сервисов, обновление которой заключалось в перетаскивании файлов и рестарте сервисов. Как понимаете, ни версионирования, ни сборки — не было. Приходилось делать сборку на MS-студии и перекладывать файлики. Понять, что все плохо, можно было, только если какой-либо сервис не стартанул, ну или начинали звонить — что-то перестало работать. Вторую систему только купили — это был калькулятор на базе Oracle, — и начали думать о ее внедрении; сторонних сервисов и вовсе не было.
Со временем стала расширяться инженерная служба, появился отдел архитектуры и в компанию стали выбираться средства, благодаря которым можно начать CI/CD.
В качестве используемых технологий будут освещены: Bamboo / Bitbucket / Jira / Confluence / Atlassian / Ansible / OpenShift / SonarQube / Splunk.
В конце — как всегда, After-Party, пообщаться и выспросить всё у докладчиков. Обязательно регистрируйтесь по ссылке, мы просматриваем все заявки в течение пары дней.
О новых событиях серий DevOps, @Kubernetes Meetup и других мероприятиях Mail.ru Cloud Solutions мы сразу сообщаем в нашем канале в Telegram: t.me/k8s_mail
Хотите выступить на следующем DevOps Meetup? Заявку можно оставить здесь: mcs.mail.ru/speak
Автор: schrc
