РИТ - Российские Интернет Технологии. Большая конференция по различным направлениям. 6 потоков — бекенд, фронтенд, devops, qa, менджмент, психология в бизнесе. Проводилась в Сколково. Если хочется получить знания в ширь а не в глубь, вам сюда.

ritfest2019

На этой конференции я был впервые, по масштабу наверное можно сравнить с CodeFest. Проходила в два дня, был афтепати, квиз, стенды, розыгрыши, за лучшие вопросы на докладах давали книжки (я получил две). Решил не сидеть на одном потоке, а сходить на все, и это мне удалось. Интересно было смотреть как меняется аудитория в зале в зависимости от потока. В целом впечатление от конференции у меня хорошее, рекомендую к посещению.

День 1

Логи не нужны. Алексей Данилов (Яндекс)

Мне как разработчику тема логирования интересна — что логировать, на какие виды делятся логи, куда логировать, как логировать. Алексей рассказал что у них было сначала — 18 ТБ неструктурированных логов в день, долгий поиск. Далее начался переход на структурированный (JSON) формат логов, был написан свой docker драйвер для логов, далее логи через очередь заливаются в MapReduce, ClickHouse, Humio. Это дало общий формат, быструю заливку, быстрый поиск.

Другая проблема — а что именно писать в лог. Была приведена следующая типизация сообщений:

  • Just in case
  • Fatal/Critical error
  • Not critical error
  • Warning
  • Tracing
  • Initial information
  • Execution time
  • Business info
  • Performance

И основной посыл в том, что все эти сообщения не нужно писать в stdout, а нужно распихивать по различным сервисам:

  • just in case — не нужны
  • fatal/critical — в Sentry
  • warning это метрики — в Grafana
  • tracing в Jaeger
  • execution time это метрики — в Grafana
  • bussines info нужно для аналитики - ClickHouse, Tableau
  • performanc метрики — в Grafana
  • debug практически не нужны

Итог доклада — логи нужны, но немного. Остальное все нужно рассылать по сервисам.

4/5

Can Distributed Teams Deliver Quality? Егор Бугаенко (Zerocracy)

За Егором слежу давно, идеи у него интересные. В этом докладе он рассказывал про свой опыт построения распределенных команд, и почему они лучше чем “команда в офисе”.

Сначала рассказл о том, что такое качество, и что разработчиков нужно “принуждать” к качеству, и им на самом деле это нравится — для них это вызов. Дальше начал приводить конкретные советы, что нужно сделать, чтобы поднять качество:

  1. master ветка должна быть только для чтения. Все изменения должны приходить из PR.
  2. Нужно чтобы сборка была хрупкой (strong pipeline). Например если тест не проходит, то сборка не должна проходить.
  3. Код ревью должен быть обязательным и объективным.
  4. Успех должен поощряться, а ошибки называться.

Тезисы, почему качество не может быть достигнуто в локальных (co-located) командах:

  1. Чаты, разговоры. Когда люди обсуждают что-то между собой, знания остаются в их головах, а не фиксируются в тикетах/вики/документации. Получаются что головы людей “богатеют”, а проект беднеет. В итоге информацию невозможно найти, нужно пересказывать ее каждый раз, и повышаются риски во время ухода сотрудника.
  2. Предвзятость. Все мы люди, и живем в социуме. Есть ярлыки и стериотипы, который мешают принимать объективные решения во время код ревью и обсуждений.
  3. Дружба. Я бы отнем к предвзятости. Посыл такой, что когда мы работаем в одной комнате, мы становимся друзьями (или врагами), что в итоге может приводить к неправильным решениям на код ревью. Можно давать послабления, или наоборот, придираться к мелочам.
  4. Месячная зарплата. Мысль в том, что когда человек знает, что в не зависимости от результата, в конце месяца он получит зарплату, то он перестает напрягаться, либо у него падает мотивация.

Почему распределенные команды лучше:

  1. Нет разговоров, все знания находятся в проекте. Был задан вопрос про чаты — в организации Егора они запрещены. Все общение через тикеты на Гитхабе.
  2. Нет предвзятости, так-как видно только никнейм человека. Потом уточнил что на самом деле она может быть, но сильно меньше.
  3. Нет дружбы, так-как проблематично дружить удаленно.
  4. Нет месячной оплаты. Тут наверное больше про платформу Zerocracy. Она построена так, что там платят за результат. Ревью, баг-репорт, выполнение тикета — все это оплачивается отдельно. Не сделал тикет — тебе не заплатили, слишком долго делаешь — получаешь меньше.

Проблемы у такого подхода:

  • Так могут работать только middle и senior разработчики.
  • Найти нужных людей очень тяжело.

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

  • У проекта должен быть архитектор.
  • Архитектор должен проводить финальное ревью PR.
  • Архитектор делает каркас проекта.
  • Архитектор понимает вектор развития проекта.
  • Плохо, если архитектор уходит. Его нужно держать всеми силами.
  • Во время код-ревью нужно найти как минимум 3 ошибки. Любых. Иначе будет не код ревью, а просто нажимание кнопочки.

Итог — мысли интересные, в корпорациях можно применить, но не все.

5/5

Blameless environment: никто не должен писать качественный код. Никита Соболев (wemake.services)

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

2/5

Бесчеловечный CI/CD. Андрей Куковеров (Veeam Software)

Подход к созданию своего pipeline для сборки, тестирования и выкладки. Доклад оставил у меня смутные впечатления. Начали что-то там делать в k8s, потом прикрутили Jenkins, написали какой-то push receiver на Golang, который принимает хуки от Gitlab, написали на Ansible конфигурацию для k8s, конфиги на Groove, и стало все хорошо. Из зала задали вопрос, что мол зачем вы велосипед избрели, что есть Helm (впервые о нем слышу), на что докладчик ответил — “ну да, изобрели”

Возможно я просто плохо слушал.

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

2/5

Как не проспать проблемы проблемы в базах данных Postgres. Николай Самохвалов (PostgreSQL.support)

Николай занимается конслатингом PostgreSQL в США. Его компания делает анализ БД, показывает где проблемы, и что и как нужно поправить.

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

  • Ресурсы (hardware, os, pg version, extensions)
  • Нагрузка (tps, qps, r/o queries)
  • Разница между мастером и репликой
  • Диагностировать утечки
  • Существующие или потенциальные узкие места

Все это умеет делать утилита postgres_dba, я так понял что это сборник популярных решений. Но эта утилита не про автоматизацию, и была сделана другая утилита postgres-checkup. Она умеет строить всякие разные отчеты, и отдавать их в json. Получатся этакий линтер для Postgres. Отчеты эти сделаны исходя из опыта этой компании, и сейчас они могут по отчету бесплатно дать рекомендации, как можно улучшить БД.

Итог — узнал полезный инструмент, и немного о том, на какие значения можно смотреть в БД.

4/5

Объективная оценка людей в IT. Георгий Могелашвили (Booking.com)

Георгий рассказал про Ревью 360, которое они проводят в своей компании, и что на основании его получается объективно оценить людей. Самую интересную информацию про формальное определение уровней разработчиков и оценок ему разглашать нельзя. С его слов система сбора фидбека (не анонимная) у них работает хорошо, все дают какую-то полезную обратную связь друг на друга.

Итог — нового ничего не узнал, на свои вопросы не получил конкретных ответов.

3/5

The Future. Андрей Аксенов (Авито & Sphinx)

Довольно сумбурный доклад. Андрей большую часть времени показывал как развивалось IT с 60-х годов, как и что придумывалось, какие технологии, какие алгоритмы. И дальше сетует на то, что в 2019 году ничего нового не придумали, что только начали реализовывать технологии, которы были придуманы давно (прим. модель акторов, saga, paxos ), что С++ нужно закопать, и что есть куча языков и библиотек, и непонятно как с этим жить. В конце дал абстрактный совет, что не нужно думать, что вы все знаете.

Итог — много сетований, мало конкретных предложений.

2/5

День 2

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

Митап DDD

Если коротко — две пиццерии (DoDo и еще какая-то) обсуждали как они все написали на DDD, и какие есть проблемы. Мне было интересно узнать, кто и как использует DDD, и в какой степени, но в итоге разговор ушел в обсуждение каких-то деталей реализации. Интересно что проект сделан на PHP, и сколько я смотрел докладов про DDD и CQRS, там тоже в основном PHP. Мое мнение — подход не популярный, и про возникновении вопросов практически не с кем их обсудить.

Итог — особо ничего нового, чего не написано в книге Эванса, я не узнал.

2/5

Аварии помогают учиться. Алексей Кирпичников (СКБ Контур)

Алексей рассказал про практики SRE в СКБ Контур, что они считают аварией, как они пишут отчет по авариям, как они анализируют причины.

Определние факапа от Контура:

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

Отметил для себя полезные советы во время написания отчета:

  1. Нужно писать отчет во время пожара — метка времени, и коротко что наблюдалось. Хронологию событий потом очень сложно восстановить.
  2. После пожара сделать нормальный отчет. Нужен шаблон, по которому этот отчет будет заполнятся.
  3. В отчете указывать глоссарий. Многие термины могут быть неизвестны людям со стороны.
  4. Делать копии чатов, графиков. Имеется ввиду не вкладывать в отчет ссылки, а например скриншоты. Ссылки имеют свойство портится, сообщения из чатов удаляются, графики агригируются.
  5. Отчет нужно писать в багтрекере.
  6. В отчете нужно указыать общую длительность и тип аварии.

Был интересный вопрос из зала — как заставить разработчиков писать отчеты. Короткий ответ — никак не заставить.

Итог — есть о чем задуматься, был передан личный опыт.

4/5

Как мы построили сервис распределенных очередей в Яндексе. Василий Герасимов (Яндекс)

Василий рассказал про Yandex Message Queue в Яндекс.Облаке, аналог Amazon SQS. В докладе смешались и высокоурвневый обзор, и детали реализации архитектуры и алгоритмов, из-за чего лично у меня впечатление смазалось.

Итог — сервис интересный, можно пробовать.

3/5

Эффект поведенческой экономики в ИТ подборе. Людмила Клепова, Инга Есакова (Atsearch.ru)

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

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

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

Итог — по большей части вещи очевидные, полезного для себя выделил мало, и тема мне не особо интересна.

2/5