Привет, друзья. Без громких слов, приглашаем всех 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

Комментарии (2)


  1. Vadem
    15.08.2019 20:06

    Традиционный вопрос: трансляция/запись будут?


    1. schrc Автор
      16.08.2019 11:20

      Будут. Ссылку кинем сюда: t.me/k8s_mail