РИТ - Российские Интернет Технологии. Большая конференция по различным направлениям. 6 потоков — бекенд, фронтенд, devops, qa, менджмент, психология в бизнесе. Проводилась в Сколково. Если хочется получить знания в ширь а не в глубь, вам сюда.
На этой конференции я был впервые, по масштабу наверное можно сравнить с 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)
За Егором слежу давно, идеи у него интересные. В этом докладе он рассказывал про свой опыт построения распределенных команд, и почему они лучше чем “команда в офисе”.
Сначала рассказл о том, что такое качество, и что разработчиков нужно “принуждать” к качеству, и им на самом деле это нравится — для них это вызов. Дальше начал приводить конкретные советы, что нужно сделать, чтобы поднять качество:
- master ветка должна быть только для чтения. Все изменения должны приходить из PR.
- Нужно чтобы сборка была хрупкой (strong pipeline). Например если тест не проходит, то сборка не должна проходить.
- Код ревью должен быть обязательным и объективным.
- Успех должен поощряться, а ошибки называться.
Тезисы, почему качество не может быть достигнуто в локальных (co-located) командах:
- Чаты, разговоры. Когда люди обсуждают что-то между собой, знания остаются в их головах, а не фиксируются в тикетах/вики/документации. Получаются что головы людей “богатеют”, а проект беднеет. В итоге информацию невозможно найти, нужно пересказывать ее каждый раз, и повышаются риски во время ухода сотрудника.
- Предвзятость. Все мы люди, и живем в социуме. Есть ярлыки и стериотипы, который мешают принимать объективные решения во время код ревью и обсуждений.
- Дружба. Я бы отнем к предвзятости. Посыл такой, что когда мы работаем в одной комнате, мы становимся друзьями (или врагами), что в итоге может приводить к неправильным решениям на код ревью. Можно давать послабления, или наоборот, придираться к мелочам.
- Месячная зарплата. Мысль в том, что когда человек знает, что в не зависимости от результата, в конце месяца он получит зарплату, то он перестает напрягаться, либо у него падает мотивация.
Почему распределенные команды лучше:
- Нет разговоров, все знания находятся в проекте. Был задан вопрос про чаты — в организации Егора они запрещены. Все общение через тикеты на Гитхабе.
- Нет предвзятости, так-как видно только никнейм человека. Потом уточнил что на самом деле она может быть, но сильно меньше.
- Нет дружбы, так-как проблематично дружить удаленно.
- Нет месячной оплаты. Тут наверное больше про платформу 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 в СКБ Контур, что они считают аварией, как они пишут отчет по авариям, как они анализируют причины.
Определние факапа от Контура:
- Внешние или внутренние пользователи заметили деградацию сервиса.
- Повезло, а в следующий раз может не повезти.
- Инцидент касается нескольких команд.
- Хотя бы один инженер считает, что это инцидент.
Отметил для себя полезные советы во время написания отчета:
- Нужно писать отчет во время пожара — метка времени, и коротко что наблюдалось. Хронологию событий потом очень сложно восстановить.
- После пожара сделать нормальный отчет. Нужен шаблон, по которому этот отчет будет заполнятся.
- В отчете указывать глоссарий. Многие термины могут быть неизвестны людям со стороны.
- Делать копии чатов, графиков. Имеется ввиду не вкладывать в отчет ссылки, а например скриншоты. Ссылки имеют свойство портится, сообщения из чатов удаляются, графики агригируются.
- Отчет нужно писать в багтрекере.
- В отчете нужно указыать общую длительность и тип аварии.
Был интересный вопрос из зала — как заставить разработчиков писать отчеты. Короткий ответ — никак не заставить.
Итог — есть о чем задуматься, был передан личный опыт.
4/5
Как мы построили сервис распределенных очередей в Яндексе. Василий Герасимов (Яндекс)
Василий рассказал про Yandex Message Queue в Яндекс.Облаке, аналог Amazon SQS. В докладе смешались и высокоурвневый обзор, и детали реализации архитектуры и алгоритмов, из-за чего лично у меня впечатление смазалось.
Итог — сервис интересный, можно пробовать.
3/5
Эффект поведенческой экономики в ИТ подборе. Людмила Клепова, Инга Есакова (Atsearch.ru)
Не знаю как меня сюда занесло. HR рассказывала, как нужно вести себя с кандидатом, основываясь на психологии. Что запомнил:
- Зовите кандидата на подписание офера в офисе.
- Давайте офер на фирменной бумаге.
- Дайте понять что офер имеет определенный срок.
- Сделайте нормальный сайт компании.
- Рассказывайте о плюшках компании постепенно.
- Можно делать фиксированную зарплату, а повышение закладывать в бонусную часть.
- Перед выдачей офера познакомьте кандидата с командой.
Ничего не могу сказать на счет того, как хорошо работают эти советы. Некоторые наверное хорошо, некоторые не очень. Как по мне, фокус на психологии и маркетинге, а не на качестве, к хорошему не приведет. Нормально делай — нормально будет.
Итог — по большей части вещи очевидные, полезного для себя выделил мало, и тема мне не особо интересна.
2/5