В докладе пойдет речь о запуске ГС Мир/ГС ПВДНП (Государственной системы изготовления, оформления и контроля паспортно-визовых документов нового поколения) не просто на Open Source-стеке, а еще и на отечественных процессорах Эльбрус.

Изначальная архитектура системы уже включала Open Source-решения (например, Linux в качестве основной OS и PostgreSQL в качестве основной СУБД на территориальных объектах), но важный компонент системы - ЦОД - был реализован с помощью привычных промышленных решений: мейнфреймы, IBM DB2, for z/OS,IBM WebSphere MQ, IBM Tivoli. Но время внесло свои коррективы, и сейчас система полностью переведена на PostgreSQL, Ceph, Apache ActiveMQ, Redis, Zabbix, OTRS и другие элементы Open Source-стека. Вдобавок ко всему, это первая столь масштабная система, полностью переведенная на платформу МЦСТ Эльбрус.

Как можно взять и перевести такую критическую систему на непривычный стек? Какие есть плюсы и минусы у традиционного и нового стека технологий? В чем различия в эксплуатации и разработке? С какими трудностями столкнулись и какие архитектурные подходы пришлось поменять? В чем различия в структуре стоимости владения такой системой? Как обеспечить zero-downtime миграцию такой системы?

Обо всем этом пойдет речь в нашем докладе.

Что такое DevOps? Очередной модный термин? Методология? Набор инструментов? Культурные практики?

Для Райффайзенбанка DevOps - микс из всего перечисленного (смешать, но не взбалтывать!), применяемый чтобы:
- ускорить разработку и внедрение новых решений не в ущерб качеству;
- вовлечь админов в работу девелопмента;
- заинтересовать разработчиков жизнеспособностью их творений в реальной жизни.

DevOps в Райфе - одна из ключевых историй в ИТ-стратегии Банка, разветвленная программа, включающая в себя три больших стрима:
- Культура.
- Организация.
- Технологии.

У программы есть четкие цели, весьма расплывчатые границы и нет совсем никакого плана.
Зато она постоянно приносит новые изменения в жизнь сотрудников трех больших подразделений.

Как мы к этому пришли, что конкретно делаем, и как все это приживается в умах и действиях людей - расскажу подробнее.

Все, кто перешёл на сторону Agile, знают, что бесполезно детально планировать проекты по разработке ПО на длительный срок, но почему-то не все из них понимают, что проект Agile-трансформации детально планировать так же бессмысленно.

Когда мы стартовали масштабную трансформацию, мы были сильно вдохновлены опытом компаний Spotify и ING, кроме того, "старшие товарищи" нас убедили, что SAFe - чуть ли не единственный способ построить Agile в такой большой организации как Сбербанк. Конечно, когда мы начали Agile-трансформацию в банке, мы столкнулись с множеством вызовов, но в докладе расскажу про опыт трансформации трёх продуктовых групп, каждая из которых состояла из трёх Scrum-команд.

В начале мы поняли: у нас не получается найти для каждой Scrum-команды достаточно опытных ребят, чтобы стать владельцами продуктов. Точнее, формально Владелец Продукта был у каждой команды, фактически у каждой продуктовой группы из трёх команд был только один человек, способный выставлять бизнес-приоритеты.

В итоге у каждого продукта был общий бэклог, и только на планировании очередного спринта команды разбирали его элементы в собственные бэклоги спринта. Таким образом, мы немного неожиданно для себя победили вторую проблему. Исторически каждая команда продукта имела свою специализацию, но жизнь оказалась богаче и нередко случалось такое, что у одной команды по её профилю недостаёт задач для спринта, а у другой было чересчур много. Наличие общего бэклога дало простой способ помогать перегруженной команде.

Но были и другие вызовы в масштабировании Scrum: понятно, раз уж команды работают над одним продуктом, то между ними есть зависимости и стоит их отслеживать почаще, чем раз в неделю. Попытки организовать PO Sync, как в SAFe, не везде увенчались успехом. Каждая из продуктовых групп пришла к своему решению: одна группа адаптировала встречи из прошлой жизни, вторая взяла церемонии синхронизации из SAFe, третья - из LeSS.

Интересно, что в одной из продуктовых групп мы осознанно отказались от собственных ретроспектив в командах и оставили только общепродуктовую. А в других группах этого позволить себе не могли, т.к. там были вновь собранные команды, и групповая динамика в них была на начальном этапе кривой Такмена, а внутрикомандные ретро - самый мощный инструмент именно для прохождение этапа шторма в новых командах.

Кроме того, постараемся успеть обсудить, как такой подход применяется в зависимости от распределённости команд.

Сейчас в HR идет процесс слома, когда технологии начинают играть все большую роль в принятии решений. Главное преимущество использования технологий в HR – возможность начать измерять эффект воздействия HR на бизнес.

Digital HR / HR 3.0 — это подход к управлению человеческим капиталом как активом, построенный на принципах измеримости, интеграции данных, анализа в реальном времени и технологической гибкости.

В рамках доклада мы расскажем про уникальность концепции HR 3.0 — про интегрированные HR-процессы, культуру вовлечения и управление человеческим капиталом как поиск и поддержание оптимального экономического баланса между работником и организацией, а также на ярких примерах продемонстрируем:
— эволюцию HR-функций;
— формирование капитала в HR;
— суть цифровых HR-процессов;
— современный подход к выбору ИТ-систем.

Соединение управления человеческим капиталом как активом с возможностями стремительно развивающихся цифровых технологий позволит сделать процесс управления людьми таким же прозрачным, последовательно выстроенным и измеримым, как управление любыми другими процессами компании.

Распознавание образов, телемедицина, интернет-вещей, bigdata, блокчейн и уберизация меняют нашу жизнь.

Как к IT-трендам относится государство? Что из технологий мы планируем регулировать, что будем использовать и на что делать ставку?

Государственные сайты, чтобы быть востребованными "потребителями", должны строиться на основе их нужд. С другой стороны, к ним существует целый ряд обязательных к выполнению требований. Нахождение баланса при разработке - весьма непростая задача. Мы попробуем её раскрыть.

Кроме того, государственный сайт всегда "принадлежит" какому-то учреждению и, согласно законодательству, должен раскрывать информацию о его деятельности. Вот только границы этой деятельности не всегда очевидны простым смертным, а язык, на котором это раскрытие происходит, вроде и русский, да не совсем.

Как же построить правильный государственный сайт?

Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.

За этот год обе команды собрали уникальный опыт работы на стыке web и enterprise. В докладе мы расскажем о процессе совместной работы вендора и интегратора на реальном примере с каждой из сторон: взглядах команд на проект, целях, процессах разработки, подходах к решению задач, QA и эксплуатации получившегося продукта. Подробно опишем проблемы, с которыми мы столкнулись на каждом из этапов (от составления ТЗ до production), как их решали, как разделяли обязанности и как в итоге пришли к четкому и прозрачному процессу работы.

Выводы на основе полученного опыта могут быть интересны как руководителям, так и разработчикам.

Вводные:
1) Необходимо переносить данные с минимальным простоем БД.
2) Необходимо произвести трансформацию данных из-за отличий между DB2 и PG и перемещением BLOB'ов в Ceph.
3) Перенос должен быть произведен за приемлемое время.
4) Нужно учесть зависимости между таблицами.

Технологии:
1) Отслеживание изменений с помощью триггеров.
2) Анализ зависимостей с помощью доработанного SchemaSpy.
3) Перенос с помощью Spring Batch.
4) Разбиение на партиции (два подхода: деление диапазона id между min и max на равные части; деление на диапазоны с равным числом строк).

Teradata, Exadata, Netezza и другие представители мира машин баз данных в этом докладе будут классифицированы, препарированы, а также будет обсуждена задача создания новых таких машин.

Все эти машины — не просто сбалансированные комплекты из серверных узлов с предустановленной СУБД в той или иной конфигурации. Во всех случаях в них реализованы программные специфики, подразумевающие применение архитектурных или аппаратных возможностей, недоступных «вразвалку» (хотя в некоторых случаях есть возможности по воссозданию отдельных их элементов в лабораторных условиях, и об этом тоже будет в докладе). Таким образом, этот материал не столько о том, в шкаф какого цвета разные вендоры упаковали свою продукцию, сколько об идеях, заложенных внутри этих комплексов.

Вся проблематика машин баз данных тесно переплетена с применением основных архитектурных шаблонов, относимых к «веб-масштабу»: массовый параллелизм, гипреконвергенция, дезагрегация хранения и обработки, исключение единых точек отказа, использование компонентов массового класса — всё это было определяющим для развития этого сегмента enterprise-оборудования, и в той или иной степени воспроизводилось в решениях интернет-гигантов, возможно лишь на новом уровне и в новом масштабе. Рассмотрение этих аспектов послужит параллельной канвой для выступления.

Тема: Web-driven enterprise инфраструктура в современных ДИТ (департаменты информационных технологий).

В своей практике я часто сталкиваюсь с тем, что задача от бизнес-заказчика спотыкается о невозможность реализации нужного функционала в желаемые сроки: или система не готова к перезапуску, или "сотрудники ИТ распланированы на ближайшие два квартала, приходите в конце года". Современный ДИТ должен отвечать требованиям времени: скорость, гибкость, клиентоцентризм - все это должно стоять во главе стратегии развития. В своем докладе я постараюсь осветить самые горячие, на мой взгляд, проблемы и показать пути их решения.

Тезисы:
- Что такое web-driven enterprise инфраструктура.
- Самые горячие проблемы ДИТ и варианты их решений.
- Каким должно быть современное ИТ-подразделение.
- Сравнение old school и new age подходов ДИТ в разрезе специалистов, расходов и time-to-market.

1. Краудсорсинг - один из лучших инструментов привлечения жителей города к его совместному управлению.
2. Вы не представляете, сколько идей, о том как сделать город лучше, есть у его жителей.
3. Хочешь лояльного жителя - предложи ему вместе управлять городом.
4. Elon Musk (Илон Маск) в своем интервью назвал краудсорсинг одним из инструментов, который обязательно должен быть в любой компании.

В докладе:
1. Проблематика, для решения которой внедрялся краудсорсинг.
2. Система городских решений "Вместе": как взаимодействуют городские проекты краудсорсинг (crowd.mos.ru), система электронного референдума "Активный гражданин" (ag.mos.ru) и портал "Наш город" (gorod.mos.ru).
3. Подробнее о краудсорсинге: как устроена проектная схема - от формирования темы проекта до контроля реализации идей.
4. Как устроен проект изнутри: три схемы проведения проекта с пошаговым разбором основных вех.
5. Примеры, как надо делать и как не надо делать при внедрении краудсорсинга.

Для кого-то Agile - рутина со своим местом в системах управления. Для кого-то - модный тренд, который теперь во что бы то ни стало надо применить, даже если в этом нет необходимости.

Мы - группа компаний с традиционным производственным укладом, со штатом в более 28 тысяч человек и парком техники более 14 тысяч единиц. Проблема таких компаний в том, что несмотря на стек перспективных начинаний, как только настает момент практической реализации, все затухает, сталкиваясь с инерционностью, непониманием необходимости что-то менять, культурой организации. Очевидно, что здесь все и всегда шло по водопаду и все инициативы, в том числе инновации в IT проходили долго, теряя темп и актуальность.

Я расскажу про наш опыт внедрения типовой задачи IT в крупной корпорации - внедрении единого документооборота, который мы впервые внедрили по принципам Agile, повернувшись лицом к разработчикам, нарушив устоявшиеся процессы и изменив регламенты.

Что мы получили:
- Кучу шишек!
- Ни с чем не сравнимый опыт!
- Уроки и открытия на будущее.
- Работающую систему, внедренную за непривычно короткие для нас сроки и с минимальными ресурсами!

Несколько лет ведущие аналитические агентства рассказывали нам о грядущей эпохе цифровой экономики, предрекали цифровую трансформацию для множества традиционных индустрий и рисовали в триллионах долларов эффект от внедрения современных технологий, будь то интернет вещей или искусственный интеллект. Кажется, настало время разобраться, что же происходит на самом деле.

В докладе я расскажу, почему цифровая трансформация - это естественное следствие повышения роли ИТ в бизнесе, как в разных компаниях возникает эффект теневого ИТ, и какие риски он несет для существующих ИТ-подзраделений. Поговорим о том, как начать думать новыми категориями: от работы в облачной и гибридной моделях распределения данных и ресурсов до переноса идей DevOps на весь бизнес, и какова роль Open Source решений в этой трансформации.

На нескольких реальных примерах рассмотрим, как от внедрения небольших инноваций можно двигаться в сторону data-driven бизнеса. Например, как от простой задачи распознавания голоса в узком сценарии перейти к обновлению всей бизнес-модели взаимодействия с пользователями, а от бизнес-идеи создания франшизы перейти к data-driven моделям развития ИТ-инфраструктуры. Наконец, посмотрим на некоторые цифры из исследований, во что сейчас инвестируют разные компании, какие видят риски и проблемы на пути цифровой трансформации.

Термин "омниканальность", пришедший на смену "мультиканальности" стало одним из самых модных и популярных слов , которое упоминают последние несколько лет, когда обсуждают направления развития розничных сетей. Он возник как ответ на попытку интернет-игроков вытеснить бывших оффлайн-гигантов, например, Amazon vs Walmart.

Однако, как это часто бывает, за достаточно простой идеей иногда скрываются пустота и полное отсутствие понимания, как это реализовывать.

Мы с Вами:
* попытаемся от пустых лозунгов перейти к обсуждению возможных механизмов реализации этой концепции;
* обсудим, какие решения необходимо принять, и что на них влияет;
* рассмотрим, что действительно является ядром омниканальности, а что туда свалено до кучи (как это обычно бывает с общеупотребительными Buzzword'ами);
* рассмотрим варианты ИТ-архитектуры;
* выясним, какие подходы работы в online очень хочется применять в offline, и почему технологии пока не позволяют этого сделать;
* обсудим, куда это будет двигаться дальше, в частности, омниканальные и персонализированные коммуникации. И да, это о том, как в будущем Ритейлеры и Производители товаров будут следить за каждым вашим шагом.

Это доклад о проектировании бизнеса на стыке онлайн и оффлайн.

Я постараюсь не обращаться к банальным лозунгам "монолит - это плохо, микросервисы - это хорошо", а постараюсь проследить генезис этого явления, очертить несколько исторических линий, которые показывают, что микросервисная архитектура - это очередной эволюционный шаг развития в ИТ предприятия.

Одна линия - требования рынка, тут располагаются тренд дигитализации и требования к нагрузке и юзабилити.
Вторая линия - ИТ-архитектура предприятия, история ее развития и смены стилей от мейнфреймов до наших дней.
И третья линия - роль архитектора, которая также с приходом MSA начинает меняться.

Я думаю, что такой многофокусный взгляд с заходом в историю дает более глубокое основание для понимания микросервисов как явления сегодняшнего дня и позволяет заглянуть в день завтрашний. Кроме того, поговорим о том, насколько этот тренд является для современных корпораций желательным/нежелательным, возможно ли его избежать, и можно ли из него извлечь преимущества, даже если на ваших масштабах всей пользы как Google вы извлечь из микросервисной архитектуры и не можете.

1. Почему мне надо верить? Мой опыт снизу и сверху.
2. Что умеют интеграторы и не умеют digital-агентства.
3. Что умеют digital-агентства и не умеют интеграторы.
4. Ошибки интеграторов и агентств на проектах.
5. Что и как выбирать клиентам? Что лучше – уверенность сейчас? Или эффективность в перспективе?
6. Чем сердце успокоится? Экосистема веб-разработок через 5 лет.