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

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

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

У нас было 30 команд, все пилили свои сервисы — иногда они падали, цепляли друг друга по пути … “Быстро поднятое упавшим не считается”, — слышали мы и продолжали падать снова. Мы не знали, сколько денег теряем, и надеялись, что “виновные” сами разберутся в Slack.

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

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

Как это сделать? Проводить внутренние митапы? Писать документацию? Менять что-то в процессах? Строить матрицы компетенции?

Формально инструментов много, но какие из них работают, а какие нет, почему и в каких условиях? Давайте вместе попробуем разобраться во всём этом, основываясь на реальном опыте.

На выходе с мозгового штурма мы хотим получить документ, исчерпывающе отвечающий на вопрос: как привить культуру шаринга знаний своей команде?

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

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

Код действительно выкидывают, если “не взлетело”. А что делать, когда тестовый запуск прошел успешно, и в нашей поделке уже живут настоящие пользователи? Часто, несмотря на все первоначальные договоренности приходится поддерживать и развивать то, что называлось MVP, дальше.

В докладе я расскажу о том, как мы запускаем новые продукты, не выкидывая исходный прототип, но и не испытывая адских мучений с поддержкой.

В одном из проектов я строил большую систему-агрегатор с нуля. Нам с командой надо было проверять различные гипотезы бизнеса, поэтому мы успешно использовали подход MVP — быстрые решения на коленке. От неудачных сразу отказывались, а удачные незаметно уходили в продакшн. За несколько лет мы накопили столько костылей, что поддержка проекта начала превращаться в сущий ад...

Борьба между бизнесом и разработкой — одна из самых распространённых проблем в IT-индустрии. Первым нужна скорость в проверке решений, а вторым — чёткое ТЗ, чтобы правильно проектировать эти решения. В своём докладе я расскажу, как можно сочетать эти на первый взгляд взаимоисключающие вещи, а также несколько поучительных историй про выброшенные в помойное ведро результаты многомесячной разработки, перегибы в ту или иную сторону, костыльный код в продакшне и цену ошибочных решений, которые принимает техлид.

Представим ситуацию: у вас имеется большой и взрослый проект с legacy-кодом. Вы установили статический анализатор, проверили код вашего проекта и получили отчёт о найденных ошибках. Сколько там их будет? По нашей статистике – несколько тысяч. Я расскажу вам, как исправить такое количество ошибок, затратив на это минимум ресурсов.

Мой доклад будет посвящён наиболее полезным практикам применения статического анализа, которые помогут вам не только справиться с ошибками в старом коде, но и не допускать появления ошибок в новом. Изложенные мной советы будут подкреплены историей о том, как два наших программиста исправили почти 2000 срабатываний статического анализатора в исходном коде Unreal Engine 4 всего за 17 рабочих дней.

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

Мало уметь хорошо поддерживать высокое техническое качество кода, надо ещё суметь доказать начальству и заказчикам необходимость вкладывать в эту работу силы и время.

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

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

Во время круглого стола обсудим животрепещущие вопросы про платформенные команды:
* Зачем они нужны? И нужны ли вообще?
* Почему в последнее время стало так модно создавать платформенные команды?
* Есть ли от них польза или это хайп?
* Почему выбор происходит в пользу платформенных команд, а не в сторону inner source?
* Какие проблемы плодятся платформенными командами и где можно "подстелить соломки", чтоб не повторять типичные проблемы?

Расскажу про одну из проблем микросервисной архитектуры — каскадный отказ системы. Это достаточно сложная проблема, так как она находится на стыке продуктовой разработки и инфраструктурной и часто остается незамеченной. В докладе будут раскрыты базовые примеры таких отказов, как с ними бороться и какие средства можно использовать для их профилактики.

Десятки продуктов, сотни пилотов, и всем нужно одно и то же. Кто-то делает inner-source, кто-то выделяет платформенные команды. Создать платформенную команду мало. Нужно суметь её не развалить до того, как платформой начнет кто-то пользоваться.

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

При разработке крупных программных продуктов, даже применяя Agile-подход, надо обеспечить соблюдение архитектурных принципов как в части конфигураций инфраструктуры, так и в части программного кода. Оптимальным способом решения данной задачи является подход governance as a code. При данном подходе правила проверки каждого артефакта — будь то конфигурация k8s, список библиотек или даже описание сценария CI/CD — описаны специальным кодом проверки правил, имеют свой жизненный цикл, подвержены тестированию и ничем не отличаются от обычного программного продукта.

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

Этот будет рассказ про то, как вносить системные изменения в работу команд. Изменения могут быть любыми: это может быть новый язык программирования, новый фреймворк или новый процесс вроде ревью кода или написания постмортемов.

Это можно делать по наитию, а можно действовать хитрее и быть более эффективным. Мы рассмотрим разные стадии внедрения и разные типы сотрудников. Разберем, как действовать в разных случаях, кого брать в союзники, а кого надо больше контролировать и зачем.

Системы непрерывной интеграции давно стали стандартом в разработке программного обеспечения и уже являются неотъемлемой частью серьезных сервисов-хостингов — travis-ci, bitbucket-pipelines, gitlab auto-devops и подобные. Но всё это инструменты, которые позволяют построить и автоматизировать процесс непрерывной интеграции, а сам факт использования этих инструментов не гарантирует наличия такого процесса в вашем проекте. Мы попробуем разобраться в самом процессе, понять, что же такое качественный ci и как с его помощью навести порядок в процессе релизов.

При создании системы на микросервисах можно легко создать распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск. О том, как именно, с примерами из практики, — в докладе.

Соблюдай технику безопасности!
• "Не ослабляй крепь при передвижке конвейера", или Как встроить AppSec в цикл разработки (S)SDLC;
• "Не проталкивай несцепленные вагонетки", или Как проверять уязвимости в сборках и контейнерах;
• "При передвижке находись под защитой секции", или Какие инструменты использовать в CI/CD-пайплайне;
• "Изменились условия — измени паспорт", или Какие артефакты подготавливают AppSec-инженер и команда.
Эти и другие техники безопасной разработки, или "Помни, работать без предохранительного пояса — опасно!"

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

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

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

Наша команда занимается построением CI/CD-решений внутри Циан. Мы начинали с написания небольших скриптов, а теперь у нас собственная система, которая "рулит" почти всем жизненным циклом задачи, начиная с момента заведения тикета в Jira. Это и работа с пулл-реквестами, исходным кодом, проведением ревью, автотестами, и выкладка в прод (зачастую без участия человека). Со временем она переросла в монолит, и поддержка усложнилась. Как разделить такой монолит? Как эффективно управлять процессами? Мы выбрали BPMN-движок от Camunda.

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

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

У вас есть техническая идея и вы хотите внедрить ее? Я обобщил полученный опыт и представлю его в виде пошагового гайда с примерами и советами. Расскажу, как сделать из идеи MVP, а MVP масштабировать на множество команд. Дам советы: как проверить вашу гипотезу, найти общий язык с бизнесом и сделать идею привлекательной для пользователей.

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

В докладе я поделюсь несколькими историями, которые помогут слушателю сделать инфраструктурные процессы явными и ускорить их.

На протяжении 5 лет мы в компании в различных проектах используем практики DDD. Они помогают нам декомпозировать системы на микросервисы, находить общий язык с заказчиком, создавать приложения, которые не сопротивляются новым требованиям, а также поддерживать качественное общение внутри команды. При этом часто от применения предметно-ориентированного проектирования отказываются из-за того, что это методология без четких указаний, что и как делать.

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

В докладе рассмотрены подходы к написанию «хорошего» кода — понятного и удобного в поддержке.

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

---

Надо делать хорошо, плохо получится само. Однако, чтобы сделать хорошо, надо видеть перед собой идеал. Бест практис в этом плане — видение, сформулированное за нас лучшими инженерами.

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

Расскажу, зачем может понадобиться обновлять технический стек в крупном проекте и что может помочь в организации этого процесса. В качестве примера — реальная история перевода на React и TypeScript проекта, в который коммитят около 70 человек в день. Проекта, который рендерит миллионы разных комбинаций поисковых результатов в день — поисковой выдачи Яндекса.

За последний год наш стартап заметно вырос. Больше клиентов, больше команд разработки, больше микросервисов. В этот период мы сделали десятки существенных (и ещё больше минорных) изменений в части инфраструктуры нашего стартапа и не собираемся останавливаться, потому что хотим, чтобы и командам жилось лучше, и клиенты получали лучший сервис, и стоимость оставалась адекватной.

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

Как часто в своей работе вы слышите слово «зоопарк»? Смею предположить, что нередко.
Как часто дискуссия про «зоопарк» ни к чему не приводит? Смею предположить, что тоже нередко.

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

Это доклад не про технологический Космос или пайплайны CI/CD. Это доклад про инфраструктурный быт и проекты длиной в пару лет, а также про минимизацию затрат и поддержку бизнес-деливери.

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

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

Легковесные языки разметки (Markdown, reStructuredText, Asciidoc) победоносно шагают по планете. Markdown понимает, кажется, каждый второй editbox в вебе.

Использовать такие языки для ведения и хранения документации — отличная идея! В них легко писать, файлы в них удобно хранить в репозитории.

Но как быть, если из сотни статей в Markdown нужно сгенерить красивый HTML-портал, а из RST — симпатичную PDF'ку в корпоративном шаблоне?

На этом мастер-классе мы поговорим о современном состоянии экосистемы инструментария вокруг легковесных языков разметки.

Костя Валеев (Ростелеком ИТ) расскажет об их in-house-продукте Foliant и о том, как из Markdown-исходников можно создавать кастомизированные PDF и HTML.

Коля Волынкин (Plesk) расскажет о том, как они генерят огромные HTML-порталы с помощью Sphinx-doc.

Семён Факторович (documentat.io) расскажет о «швейцарском ноже» Pandoc, о том, как его можно расширять с помощью Haskell, Lua и Python, и как мы с его помощью победили генерацию DOCX.

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

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

Команда фронтенда в Яндекс.Деньгах насчитывает порядка 50 человек, и нам было жизненно необходимо делиться знаниями и следить за архитектурой нашего фронтенда.

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

BDD как концепция существует с 2006 года. За это время методика, по идее, должна была бы уже прижиться и стать стандартом де-факто.

Казалось бы, что может быть проще: слушай стейкхолдера в три пары ушей, обсуждай, да записывай фичи на Gherkin, набрасывай код и автоматизируй сценарии.

Но вот почему-то в нашем домене ERP-систем истории BDD-успеха на поверку оказываются очередным набором UI-тестов, написанных постфактум.

Можно даже подумать так, что софт-индустрия взяла от методики лучшее, отбросив избыточное.

Но, на мой взгляд, не всё так однозначно. В докладе я изложу своё виденье проблемы встраивания BDD в рабочий процесс разработки ПО, а также расскажу о нашей попытке влить новое вино в старые меха, при этом не выплеснув вместе с водой ребёночка. Целью доклада является обозначить те вызовы, которые встают перед командой, желающей практиковать BDD, и показать ловушки, в которые можно попасть на этом нелёгком пути.

P.S.
По ходу доклада я буду использовать такие слова, как: BDD, Living Documentation, "Docs As Code", Impact Mapping, Story Mapping, Scrum, Kanban, Jenkins, Allure и другие термины из лексикона Agile-коучей. Но никакой инфо-цыганщины, только практические моменты.

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

Практика/воркшоп по подготовке к "продаже" технических задач "бизнесу" – парная к докладу на эту же тему.

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

Писать код или заниматься стратегией технологического развития продукта и команды? Решать сложные технические задачи самому или делегировать? Эти и другие конфликты мы разберем на моем докладе, цель которого — помочь справиться с конфликтами и проблемами лидеров.

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

Я дам вам фреймворк для решения ваших проблем, а не буду грузить вас “самописным решением и костылями”.

В одной виртуальной комнате соберем разработчиков платформ Kubernetes в облаках, DevOps-инженеров и техлидов. Обсудим проблемы и сложности перехода от приватных облаков к публичным. Коснемся ошибок масштабирования и отказоустойчивости. Затронем вопросы мониторинга вашей инфраструктуры. Поделимся опытом использования Kubernetes в бою.

Спикеры:
Антон Черноусов, Developer Advocate / Яндекс.Облако
Алексей Баранов, руководитель managed k8s сервиса / Яндекс.Облако
Илья Сауленко, руководитель разработки Авито PaaS / Авито
Евгений Потапов, генеральный директор / ITSumma
Игнатов Юрий, лидер направления инфраструктурных платформ / Express.42
Даниэль Чаплин, DevOps-инженер / Клаустрофобия

Часто, посмотрев на старый код, мы говорим: "проще переписать, чем поменять". Печальнее всего, когда это наш собственный код, с любовью написанный "всего лишь" несколько лет назад.

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