За 3 последних года в Контуре случилось больше тысячи инцидентов разной степени эпичности. Причины разные: например, 36% вызвано некачественным релизом, а 14% — работами по обслуживанию железа в дата-центре. Откуда статистика? После каждого инцидента пишется отчёт — постмортем. Их пишут дежурные инженеры, которые отреагировали на уведомление об аварии и первыми начали разбираться в ее причинах. Постмортемы анализируются, выявляются и устраняются причины инцидентов, чтобы в дальнейшем подобные инциденты не возникали. Но так было не всегда.

Алексей Кирпичников (BeeVee) с 2008 года программировал в Яндекс. Пробки, работал над спортивными спецпроектами, был тимлидом команды бэкенда Яндекс.Такси. С 2014 года занимается DevOps и инфраструктурой в Контуре — разрабатывает инструменты, которые облегчают жизнь разработчиков из продуктовых команд. Идея писать и анализировать постмортемы появилась пять лет назад, и за это время постмортемы обросли шаблонами, глоссарием, памятками, скриншотами и аналитикой. Но не это самое сложное — труднее было преодолеть инертность, страхи и непонимание смысла отчетов об инцидентах среди инженеров. Что в итоге получилось и какую непоправимую пользу может нанести «диванная аналитика» — в расшифровке доклада Алексея.


Обратите внимание — под ножки стола разной длины подложены книжки «Метрики», «Тесты» и «Деплой».

Друзья, это официальное заявление Программного комитета!

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

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

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

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

Есть заблуждение, что для создания своих железок требуется знать ассемблер, C/C++, уметь управлять памятью и глубоко понимать электричество. Когда-то так и было, но технологии развиваются и сейчас для полноценной реализации своего проекта достаточно только JS!



Ок, JavaScript мы знаем, а как соединить его с железом? Какое вообще бывает железо и что умеет? Как настроить всю систему? В расшифровке доклада Виктор Накорякова на FrontendConf узнаем: как, с помощью одного лишь JS, управлять сервоприводами, как физически объединить систему с PC, и о вариантах коммуникации приложения на JS. Обсудим пакеты serialport и Firmata, serialport с самописной прошивкой на C++, Espruino и программирование контроллера прямо на JS, Raspberry Pi, HTTP в локальной сети и HTTP и MQTT через облако.

На дворе середина 2019 года, кроссплатформа плотно вошла в жизнь стартапов по всему миру, но все чаще в ее сторону смотрят и команды аутсорс-разработки, и клиенты, которые делают ставку на снижение затрат. Кто-то делает ставку на React Native, кто-то исследует возможности Kotlin Multiplatform, а новый гость подкаста AppsCast Евгений Сатуров saturovv последние полгода активно разрабатывает на Flutter, следит за обновлениями фреймворка и продвигает технологию в массы. Максимум полезных ссылок и советов для начинающего Flutter-разработчика: от гайдлайнов до репозиторием с примерами реализации архитектуры — в разговоре с Евгением.



AppsCast — подкаст, посвященный мобильной разработке и выходящий при поддержке конференции AppsConf. Каждые две недели новый гость, с которым мы с Даниилом Поповым (int02h) обсуждаем технологии, лучшие практики, жизнь разработчиков, а так же холиварим и делимся опытом.

В ежегодном опросе «The state of JavaScript» разработчики рассказывают о том, что они используют здесь и сейчас. Вопросы там знакомы и привычны фронтенд-сообществу. В 2019 году появился опрос «The state of CSS», который ввёл разработчиков в ступор. Оказывается, многие технологии разработчикам не знакомы, хотя большинство из них уже активно используются. Возможно, разработчики используют привычные инструменты и технологии, и не стремятся применять что-то новое? Возможно, просто нет задач под новые технологии? Зачем использовать CSS Grid, CSS Multi columns, там, где проще построить все на Flexbox? Возможно, это все касается старичков, а джуны уже и не знают про Flexbox и Float и в опросах не участвуют?



Сергей Попов (popovsergey), руководитель Лиги А, спикер и организатор конференций задался этими вопросами, провел свой мини-опрос и даже получил результаты от организаторов «The state of CSS». Всю информацию Сергей обработал, структурировал и получил срез фронтенд-сообщества: кто что знает и использует, где учатся верстальщики и сколько зарабатывают, какие технологии актуальны, а какие пора сдавать в переработку, и что изучать, чтобы применять всю мощь CSS. Расшифровка доклада — один из вариантов отчета по актуальному состоянию CSS, вместе с оригинальным отчетом «The state of CSS» подскажет, куда двигаться и какие технологии применять.

Осторожно, под катом много диаграмм и картинок, действительно много, но они все по делу. В хорошем качестве они тут.

Главные вопросы работы с базой данных связаны с особенностями устройства операционной системы, на которой работает база. Сейчас Linux — основная операционная система для баз данных. Solaris, Microsoft и даже HPUX все еще применяются в энтерпрайзе, но первое место им больше никогда не занять, даже вместе взятым. Linux уверенно завоевывает позиции, потому что open source баз данных все больше. Поэтому вопрос взаимодействия БД с ОС, очевидно, о базах данных в Linux. На это накладывается вечная проблема БД — производительность IO. Хорошо, что в Linux последние годы идет капитальный ремонт IO-стека и есть надежда на просветление.


Илья Космодемьянский (hydrobiont) работает в компании Data Egret, которая занимается консалтингом и поддержкой PostgreSQL, и про взаимодействие ОС и баз данных знает многое. В докладе на HighLoad++ Илья рассказал о взаимодействии IO и БД на примере PostgreSQL, но и показал, как с IO работают другие БД. Рассмотрел стек Linux IO, что нового и хорошего в нем появилось и почему все не так, как было пару лет назад. В качестве полезной памятки — контрольный список настроек PostgreSQL и Linux для максимальной производительности подсистемы IO в новых ядрах.

Казалось бы, что сложного может быть в планировании своей работы? Берёшь листок бумаги, записываешь на нём задачи, делаешь — всё просто. Но в реальности планирование почему-то не работает «из коробки».



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

Сейчас расскажу, почему так происходит. А главное — какие из «250 способов все успевать» работают и за счет каких механизмов нашего мозга.

Речь, конечно, о DevOpsConf. Если не вдаваться в детали, то 30 сентября и 1 октября мы проведем конференцию об объединении процессов разработки, тестирования и эксплуатации, а если вдаваться — прошу под кат.

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

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

Если вы бывали на HighLoad++, то знаете о традиционном митапе по Go. Активисты, интересующиеся Go, занимали зал на пару часов, представляли небольшие доклады, обсуждали насущные темы, холиварили. Были на HighLoad++ и отдельные доклады по Go.

Теперь, нам кажется, что пора выходить на новый уровень, поэтому 7 октября мы проведем GolangConf. Из названия понятно, что это конференция про Go, но этого явно недостаточно.



Мы готовим эту конференцию для:

• Go-разработчиков — тех, кто уже давно сидит на Go, кому интересно обсудить новинки, поговорить о производительности и «кишках», узнать, что меняется в Go, похоливарить о дженериках, например.
• Кроме того, поскольку Go-общество расширяется, мы ждем программистов, которые только-только переходят на Go или даже только подумывают об этом. Покажем им истории успеха, реализовавшегося с переходом на Go, или истории провала. Узнаем, что не получается, почему, какие их первые чувства, мнения, впечатления.
• Третья категория посетителей — пользователи инструментов, написанных на Go. Это популярные в рамках Cloud Native инфраструктур: Kubernetes, Docker, Terraform, Consul и другие продукты Hashicorp. На Go-конференции гости, с одной стороны, узнают, какие у этих инструментов есть проблемы, связанные с особенностями языка, а с другой — увидят, какие в Go есть вызовы и задачи, чтобы начать, например, контрибьютить в эти проекты.

Чтобы определить, какие именно темы нужно обсудить на конференции по Go, какие проблемы и задачи важны для каждой из категорий слушателей, мы собрали Программный комитет и активистов Go-сообщества. Устроили своего рода мозговой штурм. Результатами делимся с вами и, поскольку главная наша цель — развивать сообщество, надеемся на ваш отклик. Напишите в комментариях, что нужно раскрыть полнее, что совсем неинтересно, а что именно то что нужно. Посоветуйте, например, стоит ли обсуждать особенности эксплуатации Go под Windows, а то мнения разделились.

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

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

Интернет кажется сильной, независимой и нерушимой структурой. В теории, прочности сети хватит, чтобы пережить ядерный взрыв. В реальности, интернет может уронить один маленький роутер. Все из-за того, что интернет — это нагромождение противоречий, уязвимостей, ошибок и роликов про котиков. Основа интернета — протокол BGP — содержит кучу проблем. Удивительно, что он еще дышит. Кроме ошибок в самом интернете, его еще ломают все кому не лень: крупные интернет-провайдеры, корпорации, государства и DDoS-атаки. Что с этим делать и как с этим жить?



Ответ знает Алексей Учакин (Night_Snake) — лидер команды сетевых инженеров в компании IQ Option. Главная его задача — доступность платформы для пользователей. В расшифровке доклада Алексея на Saint HighLoad++ 2019 поговорим про BGP, DDOS-атаки, рубильник от интернета, ошибки провайдеров, децентрализацию и случаи, когда маленький роутер отправил интернет поспать. В конце — пара советов, как все это пережить.

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

General-трек, чтобы сделать следующий шаг по карьерной лестнице.

Introductory-трек, чтобы послушать обзорный доклад про смежные с мобильной разработкой области (от блокчейна и ML до функционального программирования и голосовых ассистентов).

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

Добавьте к этому оборудованные дискуссионные зоны, чтобы задать множество важных вопросов спикерам. А ещё мы услышали ваш фидбек и увеличили интервалы между докладами. Таким будет следующий AppsConf, если совсем коротко. А подробно, что, как, зачем, сейчас расскажу. Но сначала когда — 21–22 октября в Санкт-Петербурге.

Как вы думаете, кто лучше настроит PostgreSQL — DBA или ML алгоритм? И если второй, то пора ли нам задуматься, чем заняться, когда нас заменят машины. Или до этого не дойдет, и важные решения все-таки должен принимать человек. Наверное, уровень изоляции и требования к устойчивости транзакций должны оставаться в ведении администратора. Но индексы уже скоро можно будет доверить машине определять самостоятельно.



Энди Павло на HighLoad++ рассказал про СУБД будущего, которые можно «потрогать» уже сейчас. Если пропустили это выступление или предпочитаете получать информацию на русском языке — под катом перевод выступления.

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

Знакомьтесь, это Дима. Он тимлид и отвечает за техдолг и код-ревью, за планирование и технические процессы, за выполнение разработчиками задач в срок — мотивирует, нанимает и, если надо, увольняет. Дима хочет работать только над важными задачами, но работает над миллионом самых разных, постоянно думает о работе и не высыпается. У него все горит: сроки, задачи, время и самооценка. Дима в аду.



Знакомая ситуация? Для Алексея Катаева (deusdeorum) — точно. Алексей больше 15 лет занимается веб-разработкой как backend, frontend, fullstack-разработчик и тимлид. Сейчас Алексей работает в Skyeng и как-то раз ему удалось сделать из команды суперкоманду — лучшую в компании. И с тех пор Алексей занимается тем, что создает в Skyeng суперкоманды на постоянной основе. Как он это делает, в расшифровке доклада, который участники TeamLead Conf 2019 назвали лучшим на конференции.


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

Все хорошие стартапы либо быстро умирают, либо дорастают до необходимости масштабироваться. Мы смоделируем такой стартап, который сначала про фичи, а потом про перфоманс. Перфоманс будем улучшать с MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения «из коробки». Однако, когда нагрузка растет, вылезают грабли, о которых вас заранее никто не предупреждал… до сегодняшнего дня!



Моделирование проводит Сергей Загурский, который отвечает за инфраструктуру бэкенда вообще, и MongoDB в частности, в Joom. Также был замечен в серверной части разработки MMORPG Skyforge. Как сам себя описывает Сергей — «профессиональный набиватель шишек собственным лбом и граблями». Под микроскопом — проект, который использует стратегию накопления для управления техническими долгом. В этой текстовой версии доклада на HighLoad++ будем двигаться в хронологическом порядке от возникновения проблемы до решения с помощью MongoDB.

27-28 мая в Москве прошла отраслевая выставка и целый ряд профессиональных тематических конференций «Российские интернет-технологии 2019». Selectel традиционно поддержал мероприятие и выступил его партнером. Сегодня мы кратко расскажем, что именно запомнилось гостям и участникам.

Компания Онтико, организатор фестиваля, приложила максимум усилий для того, чтобы создать комфортное и удобное пространство как для гостей, так и для организации стендов компаний. На два дня фестиваля кампус Московской школы управления «Сколково» стал прекрасным пространством для обмена опытом и коммуникации.

РИТ++ — это профессиональный фестиваль для тех, кто делает Интернет. Прямо как на музыкальном фестивале у нас много потоков, только вместо музыкальных жанров — IT-тематики. Мы, как организаторы, стараемся угадать тренды и найти новое звучание. В этом году это «качество» и конференция QualityConf. Не обходим стороной любимые мотивы в новых интерпретациях: распил монолита и микросервисы, Kubernetes и CI/CD, CSS и JS, рефакторинг и performance. Конечно, представляем новые и хитовые темы. Всё как у людей, включая горы сложного оборудования, мерч и выпивку!

Последние два — только для гостей фестиваля. А вот оборудование пойдет в дело для трансляции. И по хорошей традиции Главный зал — то есть как раз самые востребованных «исполнителей» — мы бесплатно транслируем на нашем youtube-канале.



Подключайтесь к трансляции 27 мая в 9:30, увидите и услышите много айтишно интересного, расписание под катом.

Если вы не понимаете, что такое DevOps, то вот краткая шпаргалка. DevOps — это набор практик, которые уменьшают страхи инженеров и сокращают количество сбоев в производстве ПО. Как правило, они же сокращают время выхода на рынок — период от идеи до доставки конечного продукта до клиентов, что позволяет быстро проводить бизнес-эксперименты.

Как начать DevOps трансформацию? Если кратко: выбираем сервис, с которого начнем процесс, выявляем тех, кто имеет отношение к сервису, строим Value Stream Map, создаем временную команду, которая будет заниматься трансформацией первое время и ставим ей задачу. Повторяем цикл нужное число раз.


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

Определение DevOps очень сложное, поэтому приходится каждый раз запускать дискуссию об этом заново. Только на Хабре тысяча публикаций на эту тему. Но если вы это читаете, то наверняка знаете, что такое DevOps. Потому что я — нет. Привет, меня зовут Александр Титов (@osminog), и мы просто поговорим о DevOps, и я поделюсь своим опытом.



Долго думал, как сделать мой рассказ полезным, поэтому здесь будет много вопросов — тех, которые я сам себе задаю, и тех, которые я задаю клиентам нашей компании. Отвечая на эти вопросы, понимание становится лучше. Я расскажу зачем нужен DevOps с моей точки зрения, что это такое, опять же, с моей позиции, и как понять, что вы движетесь к DevOps снова с моей точки зрения. Последний пункт будет через вопросы. Отвечая на них самому себе, вы сможете понять, движется ли ваша компания к DevOps или в чем-то есть проблемы.