Представьте, что команда инженеров всю ночь перетаскивала в продакшен новую систему, запускала ее, утром сделала свои первые заказы и даже получила их. Они еще не знают, что случится через 10 минут, поэтому полны радости и надежд. Но потом приходит пользовательский трафик — и взрываются чаты и мониторинги…

Но давайте по порядку. Меня зовут Александр Клюшкин. Я работаю в Самокате и на нашем примере расскажу о сложностях перехода на новый стек. Зачем и кому это может понадобиться?

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

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

Меня зовут Семён Факторович, с 2012 года я занимаюсь технической документацией. Последние три года я руковожу собственным агентством documentat.io, помогая российским IT-компаниям создавать качественную документацию.

Мы пишем документацию с нуля (руководства пользователя, справочники API, архитектурную документацию) и поддерживаем уже имеющуюся и проводим консультации по настройке документационных процессов. И почти каждый запрос от наших клиентов начинается с признания: «Кажется, с нашей документацией что-то не так».

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

1) Документация полностью отсутствует.
2) Документацию неохотно пишут.
3) Документацию неохотно читают.
4) Документация есть, ее пишут и читают, но она кажется бесполезной.

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

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

На одной конференции мне задали вопрос (спасибо Александру!): как сделать стрим в PostgreSQL? Представьте, что имеется bytea и вы к нему хотите что-то дописать. Люди столкнулись с тем, что на это в PostgreSQL  тратится гигантское время  и растет WAL-трафик. 

Расскажу, что с этим возможно сделать — это будет еще один пример оптимизации TOAST (о чем я недавно писал), на на этот раз — для быстрой записи потока бинарных данных. На самом деле мой коллега, Никита Глухов, за несколько часов сделал расширение, которое «вылечило» проблему, и мы даже успели рассказать про это на сессии блиц-докладов на PGConf.Online 2021.

Данная статья — взгляд на то, как Kubernetes способен повысить уровень безопасности, упростив управление ею и ускорив внедрение механизмов безопасности с точки зрения специалиста по ИБ, который большую часть своей карьеры занимался наступательной безопасностью. Сейчас на примере Kubernetes я вижу, что на нем можно организовать так называемую self defense (самозащищающуюся) систему.

Меня зовут Дмитрий Евдокимов, я founder и CTO компании Лантри, а кто-то может меня лучше знать, как автора каналаk8s (in)security. Про безопасность я буду говорить, исходя из моего опыта, как человека, который десять лет атаковал различные системы, реализуя угрозы и риски. Ссылка на мое выступление на конференции DevOps Conf 2021 будет в конце статьи.

В Ozon поступают сотни тысяч заказов в день — при таком масштабе у пользователей неизбежно возникают очень разнообразные вопросы, которые они пишут в чат поддержки: как оплатить баллами «Спасибо», как вернуть не понравившуюся кофту или есть ли доставка в Норильск. При этом большинство вопросов в поддержку однотипны, а ответа пользователи ожидают мгновенно и в любое время суток. 

Чтобы отвечать на все эти вопросы, в Ozon есть несколько тысяч сотрудников КЦ в Твери и Тамбове, но даже при таком количестве специалистов им нужна помощь, в первую очередь по ответам на часто повторяющиеся вопросы. И самое очевидное решение — автоматизация с помощью чат-бота.

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

Это история о том, как увеличить скорость выкатки фич, но сохранить качество продукта. О болевых точках, которые замедляют разработку, и новой «болезни» — микросервисе головного мозга, которую диагностировал Михаил Трифонов, техлид фронтов в SberСloud. Он утверждает, что она приводит к росту функциональности ML Space на 683% при увеличении команды разработки всего в 2 раза. Невероятно, но бизнес-аналитика это подтверждает. Так что давайте разбираться по порядку.

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

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

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

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

Не все тилиды не знают, как можно сообща с эйчаром проводить собеседования, чтобы было интересно кандидату и полезно команде. Я хочу рассказать, как можно им вместе провести действительно классное собеседование. Моя статья основана на опыте 200+ собеседований, которые я провел, чтобы отдел из 40 с лишним человек в ЦФТ.

Сталкивались ли вы с задачей построить Enterprise-grade-приложение из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза?

Мы хотим поделиться опытом, как решили эту задачу в Netcracker. Как в этом помогла концепция Service Mesh и идея применить «микросервисную модель» и к структуре Service Mesh. Мы реализовали Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.

Сама статья основана на расшифровке выступления на SaintHighload 2021 в Питере Алексея Ефимова, системного архитектора Netcracker и руководителя отдела Cloud Core. Ссылка на запись — в конце статьи.

Переехать в микросервисы можно двумя способами. Можно построить платформу — это надежно, но очень сложно. Или можно поднять Kubernetes и начать в него коммитить новые сервисы. Переезд проходит быстро и легко, но редко получается то, на что вы рассчитываете. Например, вместо микросервисной структуры вы можете обнаружить распределенный монолит.

Многие при этом не задумываются, правильно ли они пилят микросервисы. Как в синдроме утенка: увиденное самым первым становится единственно верным решением.

Меня зовут Олег Федоткин, я Head of PaaS СберМаркет, мы занимаемся той самой платформой, которая помогает разработчикам лучше, удобнее и быстрее писать микросервисы. Мы стандартизируем всю разработку, стараясь снизить Time to Market для новых фич. Но это всё равно очень сложно. Поэтому сегодня я разберу самые распространенные микросервисные проблемы.

Микросервисы сейчас — это новый черный. Все больше и больше компаний переходят именно на микросервисную архитектуру. И при переходе ловят самые разные ошибки. Самая популярная происходит из-за того, что люди просто не готовы к тому, что их приложения начинают активно использовать сеть. Потому что IPC и RPC-запросы  — это абсолютно разные вещи.

Я техлид в команде Авито в проекте SLA. Сегодня расскажу, как мы оптимизировали сетевые вызовы, чтобы избежать проблем с сетью при переходе в микросервисный мир. Разговор будет про оптимизацию CURL-запросов, деградацию сервисов и FAIL-FAST-подходы.

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

Алекс Морозов, co-founder & CTO в компании Datafold, рассказал, как они переехали с Flask на FastAPI и поделился собственным опытом такого переезда. Это не только то, что пишут в документации, а конкретные проблемы, с которыми они столкнулись при переезде, и как они их обошли. На примерах посмотрим, что стоит сделать, а каких решений лучше избегать.

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

Заводить тест-кейсы руками в тестохранилищах — долго и скучно. Но ведь есть еще много юнит-тестов, которые пишут разработчики. И не всегда понятно, что они покрывают и как пересекаются с E2E-тестами. Head of QA в Авито, Александр Матвеев, на Test Driven Conf расскажет о том, как можно комплексно решить эти две проблемы.

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

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

Если вы хотите понять, все ли у вас в порядке в отделе QA — моя статья для вас. Я рассказываю об этом потому, что 14 лет работаю в IT, и большую часть из них — в качестве QA-лида. Я собирала QA-отделы с нуля и запускала процессы как в продуктовой компании, так и в аутсорсе, поэтому все кейсы масштабируются для компаний разных типов.

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

Привет! Меня зовут Артём Карачёв, я фронтенд-разработчик в Sportmaster Lab. Сейчас мы пишем модуль автоматизации физической фотостудии, где работают несколько фотографов, менеджеров, фоторедакторов, кладовщиков и других. Все фото кроссовок, которые вы видите в интернет-магазинах Спортмастера, снимают и загружают в базу данных именно эти люди.

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