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

Финальное подтверждение покупки происходит после сверки лога проведенных транзакций, периодически получаемых от платежного сервиса. Код в этом компоненте написан очень давно, покрыт тестами по самое "не балуйся" и не менялся уже больше года. Соответственно, теоретическое подозрение пало на изменение API платежной системы. Поход в централизованное хранилище логов показал, что ошибок обработки в этом компоненте не было за все время вообще. И тут я заметил, что после определенного момента сообщения в логах о запросе свежих транзакций пропадают. Как будто компонент упал и прекратил свою работу. Но такого не может быть, потому что он действует в рамках того-же процесса и просто запускается по расписанию в отдельном пуле потоков. После рестарта сервиса все заработало снова отлично.

И тут я вспомнил старую "страшилку" для Java разработчиков, пишущих микросервисы на Spring Boot. Она касается настройки таймаутов, которые использует автоматически создаваемый RestTemplate для установки соединения и чтения данных. Он берет их из ClientHttpRequestFactory, реализация по умолчанию которого SimpleClientHttpRequestFactory позволяет их настроить. А если не настроил, то действуют параметры по умолчанию для всей JVM, которые могут задаваться при старте JVM или снова таки будут иметь значения по умолчанию. А вот эти самые значения по умолчанию установлены в "нет таймаута". То есть, если у вас "зависает" соединение с внешним сервисом, то вы "висите" до перезапуска JVM. Что и произошло в моем случае.

Новый тест подтвердил предположение. Я в данном случае понадеялся на отслеживание зависших соединений на стороне платежной системы, а они, видимо, понадеялись на клиентов API. :) Выводы и действия:

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

Учитесь на чужих ошибках и верьте в "страшилки"! 😄

#java #resttemplate #distributed_systems

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

Начнём с почти октябрьской конференции в Одессе - JavaDay Odessa. Она пройдёт 28 сентября в новом для Украины и очень интересном на мой взгляд формате: в программе будут сугубо deep dive сессии и практические hands-on labs, где все желающие смогут попробовать что-то на практике. Приятно видеть, что локальные Java конференции оживают и приносят свежее веяние. Программа уже доступна на сайте.

На 18-19 октября запланирована большая DevOps конференция DevOps Stage. Пару лет назад у инфраструктурных инженеров в Украине не было толком своего выделенного профильного мероприятия. Теперь есть и активно развивается. Участников ждёт много технических докладов, встречи сообществ и отличный нетворкинг. Должно быть интересно.

25-26 октября в Питере состоится самая большая конференция по Java на просторах бывшего СНГ - Joker. В отдельной рекламе она не нуждается, организаторы и программный комитет каждый год стараются отбирать и готовить классных докладчиков с отличными темами.

А уже 29-30 октября в Питере пройдёт DevOps конференция DevOops. В этом году у ребят получилась очень сбалансированная и разносторонняя программа. Ну а качество проведения должно быть как всегда на высоте.

Вот такой технический октябрь получился. А за ним будет совершенно дико перегруженный конференциями ноябрь. Как будто все сговорились и в этом году решили действовать под девизом «ни дня без конференции». Но об этом через несколько недель. :)

#conferences #конференции

Я тут в последнем анонсе совсем забыл упомянуть ещё одну октябрьскую конференцию - Highload fwdays’19. Тематика высоких нагрузок и подходов, инструментов, практик в этой области всегда была достаточно популярна. Конференция молодая и будем надеяться порадует нас отличной программой. А я постараюсь поучаствовать в панельной дискуссии. :)

#conferences #конференции

В далеком 2007 году было положено начало популяризации NoSQL хранилищ и конец эры "суй все что есть в RDBMS". С того времени на рынке появилось большое количество key-value, документных, column family, графовых, time series и других специализированных хранилищ. В результате, практически каждый продукт сейчас использует гетерогенное окружение для хранения данных, а разработчики должны уметь работать с совершенно разными принципами управления данными.

И вот что интересно. Потихоньку RDBMS решения начали предоставлять опции по хранению нереляционных структур, тем самым становясь "all in one" решением для управления данными. Больше всех на этом поприще преуспел PostgreSQL, который на текущий момент имеет помимо классической реляционной модели следующие опции:

- хранение гео-данных с PostGIS;
- хранение time series данных с TimescaleDB;
- хранение key-value данных с Hstore;
- хранение JSON документов в специальном типе колонки;
- хранение графовых моделей с AgensGraph.

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

#базы_данных #postgresql

Последняя неделя выдалась очень инфраструктурной: сначала я проводил для одного клиента тренинг по переходу с классического Spring Cloud решения полностью на Kubernetes, а потом для другого клиента стартовали подготовку UAT и production окружений с четким разделением ролей в команде. Судя по реакции разработчиков на такое многообразие экспертных областей (виртуализация, сетевые настройки, безопасность, мониторинг, логирование, балансировка нагрузки, отказоустойчивость и т.д.), с применением микросервисных подходов команда наживает себе большие сложности с инфраструктурой. Я попробовал расписать опции с плюсами и минусами для стартующей команды разработки, которая собирается иметь 5+ микросервисов.

1. Уйти полностью в PaaS:

+ разработчики гораздо меньше работают с инфраструктурой;
+ ответственность за большую часть инфраструктурного стека на PaaS провайдере;

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

2. Разворачивать managed Kubernetes у облачного провайдера:

+ меньше заморочек с управляющими сервисами;
+ готовые вспомогательные сервисы для многих областей;
+ полная гибкость в масштабировании;
+ упрощенная работа с инфраструктурными элементами;

- разработчикам нужно изучать специфику облачного провайдера;
- у провайдера может быть ограничение по версиям и настройкам;
- дороже стоят вспомогательные сервисы;
- L2 и L3 поддержка инфраструктуры лежит на команде.

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

+ разработчики используют только уровень приложения и не лезут в инфраструктуру;
+ инфраструктурный инженер работает плотно с командой и видит ее боли и потребности;
+ полная гибкость в принятии и реализации решений;
+ может быть дешевле других опций за счёт разделения окружений;

- людей с такими всесторонними знаниями на рынке очень мало и можно искать долго;
- один инфраструктурный инженер принимает решения однобоко и субъективно;
- большие риски в случае его потери;
- может быть негативное перекладывание ответственности;
- возможно выгорание при попытке взять на себя все зоны ответственности, включая L2 и L3 поддержку.

4. Найм сторонней команды в формате «поддержка инфраструктуры как сервис»:

+ нет зашоренности и субъективности знаний;
+ легче балансировать нагрузку на команду;
+ обеспечение L2 и L3 поддержки инфраструктуры;
+ гибкость в финансовом плане и инфраструктурных решениях;
+ чёткие линии разделения ответственности с разработчиками;
+ применение лучших практик на опыте других клиентов;

- отсутствие плотно интегрированного человека в команду разработки;
- возможно отсутствие экспертизы с конкретными инструментами и сервисами;
- немного медленнее реагирование на проблемы за счёт удаленной коммуникации;
- нет вовлечённости как у членов команды;
- возможны проблемы с аудитами безопасности.

Как видите, все варианты имеют плюсы и минусы. Лично я стараюсь применять в таком порядке: 4->1->2->3.

#микросервисы #инфраструктура #kubernetes

Сегодня хочу поделиться с вами одним из моих любимых юмористических роликов на тему проектного менеджмента под названием «Эксперт». Многие знают его как задачу о 7 красных линиях. Для меня этот ролик всегда символизировал клиентов, которые не знают чего хотят, а также подрядчика, который готов взяться за любую работу, даже если она нереалистичная. Ещё в ролике забавно показаны бесполезные менеджеры-прослойки.

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

Такой эксперт не готов и не хочет выходить за рамки имеющихся в его голове знаний и теорий, гораздо проще для него найти несоответствия в запросах и доказать всем вокруг абсурдность задачи. Таких экспертов мы встречаем и в реальной жизни. Они уверены, что единственным решением может быть только Java, Scrum, микросервисы, AWS или ещё что-то, во что они свято верят. Не будьте такими предвзятыми экспертами!

P.S.: Решение изначальной задачи тоже можно найти на просторах интернета и даже не одно. :)

#менеджмент

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

В праздники принято дарить подарки, поэтому мы решили подарить скидку 20% для желающих посетить 22-23 ноября нашу конференцию XP Days Ukraine 2019. Получить скидку можно по специальному промокоду XPDPD20, который действует только сегодня до конца дня.

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

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

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

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

Резюмирую: не пропускайте ретроспективы, вместо этого варьируйте цели и форматы!

#менеджмент #команда #scrum

На этой неделе мы закрываем прием докладов на конференцию XP Days Ukraine 2019. Программный комитет уже утвердил часть заявок и мы опубликовали около половины докладчиков на сайте конференции. Тем не менее, есть ряд тем, которые мы очень хотим осветить и ищем для этого подходящих докладчиков с практическим опытом:

- адаптация конкретных инженерных практик для повышения эффективности разработки;
- практические примеры DevOps трансформаций и набитые шишки;
- интересные кейсы построения облачной архитектуры для оптимизации разработки продукта на определенной стадии;
- построение полноценного CI/CD процесса с современным инструментарием в микросервисном мире;
- опыт практического применения современных инструментов для расширения возможностей Kubernetes платформы.

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

#конференции #conferences #докладчики

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

С точки зрения языковых конструкций изменения минимальны. Зато на уровне оптимизации работы VM были сделаны важные улучшения. Кратенький обзор с места событий можно прочитать в статье Олега Чирухина прямо с места официального анонса свежего релиза. А на Java конференциях в ближайшие полгода нас ждут детальные доклады на эту тему.

#java

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

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

Поэтому всем рекомендую ознакомиться и если у вас есть крутые вопросы, которые не вошли в список, то добавить их туда через pull request (да, вопросы хранятся отдельным репозиторием на GitHub).

#карьера #собеседование

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

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

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

#фасилитация #Scrum #Agile

Сегодня второй раз за год побывал в роли участника на тренинге и снова убедился, что тренинги - это прямо очень круто! Я, к сожалению, не так часто нахожу время для данного формата обучении. А когда нахожу, то обычно в роли тренера. :) Но это однозначно самый эффективный и полезный способ получения новых знаний, который дает крутой толчок в развитии:

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

Не все тренинги одинаково полезны, поэтому я для себя выработал набор критериев для выбора:

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

К счастью, в Украине практически по каждому направлению есть тренинги и тренера, подходящие под эти критерии. Интересных и полезных вам тренингов!

#обучение #тренинги

Мы привыкли видеть новости о том, что развалился тот или иной стартап. Это совершенно нормально для их жизненного цикла. Но когда такая история случается с огромным игроком на рынке, то для многих людей это становится неприятной новостью. Сегодня прошла новость о банкротстве Thomas Cook. А это 600000 туристов, находящихся сейчас по разным странам, которых нужно будет вернуть домой. Мир IT Украины тоже не обошло стороной - на компанию в Ciklum работало почти 200 человек...

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

#менеджмент

Многие ищут истории успеха в применении технологии или практики среди известных компаний, чтобы научиться на их опыте. Недавно мне на глаза попался сборник переводов статей крупных компаний об успешном переезде на Kubernetes. Например, Tinder может похвастать кластером из 1000+ нод, где крутится 48000 рабочих контейнеров. Масштаб впечатляет!

#kubernetes #инфраструктура

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

В этот раз я подготовлю 3-4 совершенно новых доклада:

- про распределенные бизнес транзакции в микросервисном мире и шаблон SAGA;
- про накопленные мной из разных компаний ошибки в использовании Kubernetes;
-  про полноценное использование статических и динамических анализаторов для улучшения качества продукта;
- про мой любимый Database Rider для DB тестов на Java и его возможности, о которых мало кто знает.

Расписание выступлений уже доступно у нас на сайте. Буду рад видеть вас среди слушателей и пообщаться  на эти темы.

#доклады #конференции

Некоторое время назад я публиковал интерактивную карту технологий в мире инфраструктуры. И вот один из читателей поделился со мной ещё одной версией от CNCF (Cloud Native Computing Foundation). Эта версия более продвинутая, потому что позволяет взглянуть с разных ракурсов и поддерживается более широким кругом профессионалов.

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

Пользуйтесь на здоровье!

#технологии #инфраструктура

​​Большая часть современных IT компаний использует специализированные инструменты для эффективной коммуникации как Slack или Microsoft Teams. Но со стороны это может выглядеть очень смешно...

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