Блог компании конференции олега бунина (онтико)

Прошлый год стал немалым испытанием для многих из нас, но дал он и толчок к новому восприятию, выстраиванию новых рабочих процессов и возникновению новых вопросов. Что находится на современном срезе индустрии DevOps и каковы тренды будущего? Об этом председатель программного комитета конференции DevOpsConf 2021 Артем Каличкин рассказал во время интервью подкасту DevOps Дефлопе, а мы перенесли беседу в текстовый вариант.

Из этой статьи вы узнаете о том, кто в российском девопсе идет в ногу со временем, или даже немного опережает мировых лидеров, посмотрите на особенности командных топологий и задумаетесь о том, кого еще нужно подружить, кроме Devов и Opsов, для того, чтобы все работало отлично. А еще заглянете в закулисье DevOpsConf 2021.

Расскажи немного о себе.

С 2004 года я занимаюсь вопросами отказоустойчивости высоконагруженных систем и поддержкой mission critical systems. В индустрии, в целом, работаю уже 22 года. Последние три года я являюсь техническим директором сервисов Faktura.ru это интернет-банк как для физических, так и для юридических лиц.

Впервые на публичной конференции я выступил в 2014 году. Это был Город IT в Томске, и на ней я рассказывал про паттерны/антипаттерны отказоустойчивых приложений. Я постоянно говорю про отказоустойчивость, потому что это непосредственно имеет отношение ко всему, что касается Operations.

Мне очень близок вопрос дружбы Devов и Opsов. Если что-то не так, Opsы забывают о сне. А я, как руководитель, обычно стараюсь сделать так, чтобы спокойный сон закончился у всех причастных, чтобы все были в одном положении.

Потом я выступил на RootConf и рассказал, как мы, в рамках энтерпрайзной компании, ставили сервис на рельсы DevOps. Тогда еще доклады о том, есть ли devOps в энтерпрайзе, не были в тренде.

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

Есть ощущение, что сегодня в России индустрия финтеха интенсивно развивается.

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

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

Развивающиеся экосистемы

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

Сейчас в России многие ориентированы на движение в сторону супер-приложений и супер-сервисов B2C. Сегодня вперед вырываются те, кто задумывается о цифровизации клиентского опыта.

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

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

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

Кому полезна DevOpsConf

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

Я преподаю в Новосибирском государственном университете на факультете информационных технологий. И всегда пытаюсь донести до своих студентов: пока не взяли ипотеку, попробуйте замутить что-то свое, ведь сейчас для этого есть масса возможностей, в том числе благодаря App Store и Google Play. Каждый может попробовать написать что-то, что зайдет аудитории, не выходя из дома.

Вернемся к конференции и оценке состояния отрасли. В этом году Agile-манифест, по-моему, отпраздновал свое двадцатилетие. И мы сегодня находимся в том состоянии отрасли, когда все должны быть максимально нацелены на поиск. Казалось бы, история Agile-манифеста о том, что нужно быть гибким, адаптироваться, или умереть, уже всем приелась. Но, по факту, мы еще недостаточно научились быть гибкими. Стоит лишь вспомнить 2020 год со всеми его особенностями. COVID 2019 уже назвали главным цифровизатором. И он показал, что мы еще недостаточно трансформировались.

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

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

У меня на работе до сих пор сотрудники спрашивают о том, как мы будем работать: удаленно или в офисе? Ответов нет, но наверняка как раньше работать уже не будет никто.

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

Мы находимся в периоде пересмотра, поэтому основная цель DevOpsConf 2021 рассмотреть вопросы вокруг взаимодействия разных цехов в рамках производства ПО, вокруг доступности, отказоустойчивости SRE-практик. Потому что все это аффектит клиентский опыт. В этом году мы в явном виде ввели в тематику контекст топологии. Например, прозвучал вопрос о том, кто такой тимлид в DevOps команде. Мы его услышали и постараемся дать ответ.

Я надеюсь, что конференция будет не суммой констатаций каких-то вещей, отраслевых решений, очевидностей, а станет окном, которое открывает сознание. Что ее участники осознали нынешнюю эру поиска и начали в ней активно участвовать. На нашей конференции есть замечательный постоянный докладчик Андрей Квапил, который рассказывает про Kubernetes, но всегда задает вопрос: Почему вообще это с ним нужно делать, что за извращение?. И это искусство, в определенном смысле слова.

То есть основная цель DevOpsConf в 2021 показать все разнообразие возможностей для команды и зародить идею, что мы все динамично развиваемся, это мир возможностей, и что будет завтра непонятно? Это все можно будет посмотреть, потрогать на конференции, позадавать вопросы спикерам оффлайн?

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

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

На любой конференции я воспринимаю себя не только в роли докладчика, но в первую очередь, в роли участника. Докладчик я всего на полтора часа (40 минут доклада, и еще где-то час нужно отвести на вопросы в дискуссионной зоне), все остальное время я участник. Если я не участвую, значит, я зря потратил время и деньги.

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

Темы конференции

На конференции будут подниматься вопросы про эксплуатацию, про надежность программного обеспечения разрабатываемого продукта, про скорость процессов поставки, про командное взаимодействие. Будут ли освещены на DevOpsConf вопросы продуктовой разработки?

Таких тем в явном виде нет. Но когда мы говорим про DevOps в широком контексте, они все равно затрагиваются. Не бывает growth hacking без FastTrack, не бывает growth hacking без возможностей ставить фичу по факту ее коммита и прогона автотестов.

Что такое DevOps? С точки зрения философии Dev и Ops должны не ругаться, а научиться договариваться. Но почему только Dev и Ops? На самом деле, все участники производственного цикла для того, чтобы он был эффективен, должны научиться договариваться.

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

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

Это звучит прямо как миссия! Ровно такую цель мы старались реализовывать в рамках DevOps Life 2020. Там даже были прямые столкновения. Например, доклад о том, почему техдир не понимает продакта.

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

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

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

Тут мы снова возвращаемся к цифровизации клиентского опыта. Когда я работаю в малой команде, цель которой заключается в том, чтобы сделать удачную цифровизацию клиентского опыта, я максимально вовлечен в ментальную конструкцию вознаграждения (как потопали, так и полопали). То есть заинтересован в конечном результате: в удовлетворенности клиента.

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

Если мы работаем в парадигме малых команд, персонажа, не вовлеченного в общий процесс, перевоспитают. Либо, простите, от него избавятся. Жесткая закрытая позиция в малых командах обычно не жизнеспособна.

О командных топологиях

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

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

Навскидку, на DevOpsConf уже есть пара докладов, близких по тематике. Есть доклад о том, как используется Scaled Agile Framework, чтобы выстроить взаимодействие команд. Для меня это один из самых ожидаемых докладов из этой области.

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

Когда мы говорим о командах и их взаимодействии, мы неизбежно вспоминаем об API. Должен быть decoupling, нужны правила взаимодействия. То есть мы говорим о некой универсальности. Но чем выше универсальность, тем дороже стоимость предоставления той или иной функции. Поэтому, в том числе, многие энтерпрайз-компании, которые заточены на расчеты финансовых показателей эффективности, трясет из стороны в сторону. Потому что, с одной стороны, хочется универсальности, с другой: правда в том, что она обходится дороже.

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

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

Мне кажется, инфраструктурные и платформенные команды это что-то типа GraphQL, и меня это смущает. Во всех крупных Agile фреймворках есть подобные команды: в Nexus это infrastructure team, в SAFe system team, в LeSS undone work team.

То есть везде есть так называемые платформенные команды. Но в SAFe это норм, к ним относятся как к константе, а в Nexus и LeSS заявляется, что это переходный этап, и со временем они должны уйти.

Опять же про взаимодействие взаимодействовать нужно не только Dev и Ops, но и внутри Dev бэкендерам с фронтендерами.

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

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

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

Ожидаешь ли ты на DevOpsConf доклады об архитектуре приложения?

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

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

Простой пример: появились микросервисы. Разработчики этому рады, а классические Opsы совсем нет.

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

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

Доклады, которые хотелось бы увидеть

А что вообще ждет нас на конференции? Возможно, у тебя есть доклад, которого ты ждешь-не дождешься, чтобы послушать и обсудить его в зале?

Мне кажется, что наша конференция может стать ориентиром для того самого поиска и пересмотра, в эре которых мы находимся.

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

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

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

Поэтому тему SRE (Site Reliability Engineering) мне очень хочется прокачать. Я знаю, что у нас уже есть доклады по GitOps, по ChatOps. Это, конечно, не напрямую связано с SRE, но все же находится довольно близко. Я сам сейчас заявил доклад в названии которого значится, что SRE это тот же самый ITIL. Но уже в тезисах я напрямую говорю о том, что это то же самое, но не то же самое. По сути, речь идет о практике ITIL с человеческим лицом.

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

Вся тематика по SRE, особенно с точки зрения попытки осознать ее системно, а не как набор разбросанных практик и подходов, для меня очень интересна. Это личное, я с 2004 года по сути дела занимаюсь, помимо всего прочего, SRE. Чем бы я ни занимался и разработкой, и архитектурой, и аналитикой со SRE я остаюсь всегда, все эти 17 лет. Поэтому тема для меня важна. Надеюсь, что она будет хорошо раскрыта.

А что делать на конференции прожженным технарям? Я услышал про GitOps, про ChatOps. Будет ли Kubernetes?

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

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

Мы работаем над этим. И делаем все возможное для того, чтобы так и было.

Профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации DevOpsConf 2021 пройдет 31 мая и 1 июня в московской Radisson Slavyanskaya. Программа ожидается насыщенной! Готовы творить будущее devOps вместе? Спешите за билетами, их можно купить тут.

А уже 24 марта, 19:00 (МСК) состоится митап Настоящее и будущее DevOps. На нем поговорим о текущих задачах DevOps-инженеров и погрузимся в технические детали управления релизами бессерверных приложений (AWS) с помощью terraform. Чтобы получить ссылку на трансляцию, нужно всего лишь зарегистрироваться.

Хотите бесплатно получить материалы предыдущей конференции? Подписывайтесь на нашу рассылку.

Миллионы запросов в секунду. Сотни серверов с десятками ядер и терабайтами оперативной памяти. Много пользователей и данных. И их становится всё больше. Да, это всё HighLoad. Но HighLoad не только это.

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

Но что насчет безопасности и защиты данных при высоких нагрузках? Что думают разработчики и эксперты о внешних угрозах, которые тоже могут вывести систему из строя? О сохранении данных, их правильной передаче и использовании? Артём Гавриченков в Программном комитете отвечает за эту область на конференции HighLoad++. Сегодня он расскажет, чем наша долгожданная офлайн-встреча Highload++ Весна 2021 будет интересна и полезна любому разработчику. Доклады на конференции будут и о безопасности, и о шифровании, и о биометрии, и, конечно, о многих других смежных с безопасностью темах.

Артем, чем ты сейчас занимаешься и какое отношение имеешь именно к высоким нагрузкам?

На протяжении 10 лет я строил продукт Qrator по защите DDoS-атак. Тут, наверное, сразу понятно, где высокие нагрузки. Последние 5 лет был техническим директором этого продукта, даже больше пяти. В данный момент я директор по продукту в Servers.com это компания, которая занимается предоставлением инфраструктурных решений (bare metal cloud, облачное хранение данных, фаерволы, Managed Kubernetes), то есть опять же решения для больших нагруженных проектов.

Как давно ты в Программном комитете и как ты в него пришел?

Я выступал несколько раз на Highload, начиная с 2011 года. А в 2018-м мы пообщались с Олегом Буниным, и он пригласил меня в ПК как эксперта по защите информации, по высоким нагрузкам в плане DDoS-атак и по масштабируемым системам по сети и инфраструктуре.

Чем тебе нравится быть в ПК? Что это для тебя?

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

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

Какие темы нас ждут в разделе безопасности в этом году на конференции?

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

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

Также будет тема защиты систем управления базами данных (СУБД), отвечающая на не совсем тривиальные вопросы. Как усиление безопасности БД влияет на производительность? Что, если мы хотим применять защищенные соединения? Что, если у нас данные нужно хранить в зашифрованном виде? Как организовать аудит?

Еще будет близкая к этому тема шифрования соединений. Сейчас практически все соединения в интернете от браузера или мобильного приложения до сервера надежно шифруются, но криптография всегда повышает нагрузку. У нас будет Александр Крижановский (Tempesta Technologies) с рассказом о том, как написать быстрый TLS-хендшейк в ядре Linux. Это такой хендшейк, который эффективней на десятки процентов, чем стандартное решение он дает меньшее время задержки, то есть готов работать под большой нагрузкой.

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

Система РТЛабс рассчитана на 150 млн человек, и этого должно хватить для 136 миллионов россиян. Хотя в реальности, конечно, будет меньше. Но, с другой стороны, может быть, ее удастся расширить и на таможенный союз, например, на Беларусь.

Будут ли какие-нибудь новинки в решении известных задач безопасности?

На эту тему будет доклад от Касперского про быстрое детектирование спам-писем. Проблеме спама столько же лет, сколько электронной почте. Она никуда не уходит, с годами становится сложнее, потому что, например, Gmail или Яндекс собирают почту в большом объеме и более-менее умеют детектировать спам с минимальным количеством ошибок первого и второго рода. Но в финале это приводит к ситуации как с Ковидом. Иммунитет летучих мышей совершенно адский он выжигает вирусы каленым железом! Это очень стойкое животное. Но по каким-то эволюционным причинам эта иммунная система выборочно оставляет некие вирусы, которые летучей мыши уже вреда не причиняют, но там живут.

Так вот мы в спаме получаем ровно такую же ситуацию. Google, Яндекс и прочие гиганты выпалывают спам, который легко детектировать, но самый адский и хардкорный остается. Например, в той же корпоративной почте у нас нет доступа ко всему тому объему данных, и поэтому у нас не получается спам фильтровать так же просто. Никакие простые методы давно не работают, поскольку спам, который умеет обходить Google, он и нас обходит очень легко.

Хочу заметить, что проблема спама никогда никуда не уйдет. Есть даже категория шуток в IT-сообществе про Final Ultimate Solution to the Spam Problem. Примерно раз в год в каких-нибудь списках рассылки появляется человек, который утверждает, что он нашел уникальное полное решение проблемы спама и чего на практике никогда не случается.

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

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

Какие доклады, не связанные с безопасностью, тебе интересны самому?

По смежной теме будет доклад Василия Сошникова про API Gateway. Эта технология реально популярный хайп последних лет. Она очень часто встречается, в том числе, в over-engineering проектах. Поэтому в докладе будет обзор концепции и того, какие плюшки это нам дает и какие сложности возникают в эксплуатации. Что поможет найти ответ на вопрос: для нашего проекта API Gateway это полезный момент или просто хайп, на который не нужно тратить время?

Это действительно интересно. А ты сам на HighLoad++ собираешься посетить только то, что описал, или тебя интересуют еще какие-то доклады и мероприятия?

Уже принято 75 докладов, и есть, конечно, интересные и не только про безопасность. Например, доклад Сбербанка про борьбу с TCP Incast. Это как раз инфраструктурная часть как устроены центры обработки данных и как устроена сеть на большом проекте. Там возникают разные проблемы.

Очень интересная тема про маршрутизацию Яндекса каким образом Яндекс маршрутизирует машины, и как он это делает таким образом, чтобы экономить своим клиентам деньги, в том числе коммерческим компаниям (доставка документов, товаров и пр.). Правильным образом выстроенная простая оптимизация алгоритма начинает экономить клиентам по 100000 рублей в месяц.

Ты часто бываешь на конференциях?

С 2017 года я не пропускал ни одного HighLoad++, в том числе ни одного питерского, и ни одного РИТа, правда, в Сибирь я не ездил ни разу.

Ты сам предпочитаешь онлайн или офлайн?

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

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

Структура это должно быть выстроено обязательно, над ней нужно очень плотно работать. Обязательно делать прогоны с таймингом и пониманием того, сколько времени будет потрачено и какие вещи нужно сказать обязательно. И крайне желательно иметь примеры из жизни, потому что примером можно показать намного больше. Один пример стоит десятка слайдов.

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

Что такое Highload лично для тебя? Как бы ты описал его человеку, который не член ПК, а просто приходит туда по собственному желанию?

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

Конференция HighLoad++ 2021 пройдет уже 17 и 18 мая в Москве, в Крокус-экспо. Сейчас открыт дополнительный прием докладов по новым темам. Если вы хотите поделиться тем важным и интересным, что вы нашли, разработали и открыли во время онлайна в пандемию мы вас ждем!

Билеты можно купить здесь. И да, цена с 30 апреля вырастет, для решения осталось 2 недели.

Подписывайтесь на наши новости о конференции, чтобы быть в курсе всех изменений, новинок и интересностей!

Телеграм здесь и здесь, FaceBook, VK, Twitter.

Какие уязвимости можно найти в типичном PHP-проекте? Удивительно, но любые от слабых мест и уязвимостей в коде никто не застрахован. Чем быстрее мы их найдем, тем меньше риск для компании. Но чем лучше будем понимать, как можно атаковать наше приложение и как взаимодействуют друг с другом наши фичи, тем легче будет защитить код еще на уровне разработки. Тем более, что в PHP есть свои специфичные уязвимости те же type juggling, insecure deserialization и local file include.

Чтобы повысить уровень безопасности кода, полезно думать как хакер и тестировщик одновременно, проверяя все возможные лазейки в коде. Сканеры уязвимостей, SSL-сертификаты, аудиты и прочие многочисленные инструменты защиты будут хорошим дополнением. О том, как всё это совместить, Антон Прохоров рассказал в нашем интервью. На конференции PHP Russia 2021 Антон представит в докладе уязвимости PHP-приложений и способы их эксплуатации.

Антон, как ты вообще попал в такую интересную сферу, как безопасность?

Еще в МИФИ на факультете информационной безопасности я увлекся практическими кейсами, а на старших курсах мы с однокурсниками стали бывать на профильных конференциях (Positive Hack Days, ZeroNights). А потом увидели финал соревнований CTF по практической информационной безопасности, заинтересовались и тоже создали команду для участия.

Как ты встретился с PHP? И чем занимаешься сейчас?

С PHP была связана моя первая работа я разрабатывал модули для сайта на Drupal. Но безопасность не завязана на один язык программирования, поэтому и на соревнованиях они были совершенно разные так что я никогда не был привязан ни к PHP, ни к другому конкретному языку. Участие в соревнованиях в итоге так меня увлекло, что я захотел работать в кибербезопасности и так пришел в BI.ZONE.

Что именно ты делаешь в BI.ZONE? Как участвуешь в анализе?

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

И ты, помимо PHP, для каждого нового проекта изучаешь новый язык?

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

Насколько больше или меньше уязвимостей у PHP по сравнению с другими языками? Какие они?

Если говорить про интерпретатор языка и стандартные библиотеки, то так как они написаны на C, то в их коде часто обнаруживаются баги, связанные с управлением памятью и различными переполнениями, которые иногда могут приводить к уязвимостям. Больше их или меньше чем в интерпретаторах других языков я не возьмусь сравнивать. Из примеров можно вспомнить уязвимость PHP-FPM и unserialize. Но это довольно редкие и специфичные случаи.

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

Например?

Например, до 8 версии PHP, если при обращении к любому файлу использовать схему "phar://", интерпретатор будет воспринимать содержимое файла как Phar-архив: попытается найти в нем метаданные и десериализовать их. Если ваше приложение принимает от пользователей путь до файла и не проверяет схему, то это может в некоторых случаях привести к возможности исполнения произвольного кода на вашем сервере. Про такие нюансы я и хочу рассказать на конференции, показав примеры.

Если в PHP таких нюансов много, можно ли сказать, что он в целом более уязвим, чем другие языки?

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

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

По твоему опыту, насколько PHP-разработчики заботятся о безопасности?

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

Пример цепочки можешь привести?

Например, приложение позволяет делать скриншоты веб-страниц: мы отправляем адрес страницы и в результате получаем картинку. Но при этом на сервере проверяется, что переданный нами адрес имеет домен example.com. А теперь, предположим, что мы нашли на сайте example.com уязвимость Open Redirect, позволяющую сформировать ссылку с доменом example.com, которая при открытии будет перенаправляться на произвольный адрес, например, localhost. И вот у нас уже есть возможность делать скриншоты страниц с localhost.

Что-то еще может помочь коду быть безопасным, кроме самообразования программистов?

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

То есть и после того, как сдали проект, нужно время от времени проводить тестирование?

Да, можно добавить одну фичу и проверить ее уязвимостей нет. Добавить другую, и там их нет. Но, возможно, комбинация этих фич может привнести какую-то уязвимость. Проверки там, где это возможно нужно автоматизировать, добавлять в CI/CD сканеры уязвимостей и т.п. И конечно, обучать разработчиков, рассказывать, как писать безопасный код. Все это в совокупности, я думаю, приведет к тому, что приложение будет безопаснее. Но это не я придумал, это известная вещь Security Software Development Lifecycle.

Можно ли полностью автоматизировать проверки по безопасности?

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

А во-вторых, некоторые категории уязвимостей сканеры вообще не находят, и пока нет даже предпосылок, что это когда-нибудь произойдет. Это уязвимости, связанные с конкретной бизнес-логикой приложения. Например, в интернет-магазине есть процесс пользователь кладет в корзину товар и оплачивает его. Только здесь может быть уже множество уязвимостей, которые не являются типовыми, вроде SQL-инъекций или XSS-атак. Это может быть, например, связано с передачей отрицательной суммы или неправильной обработкой скидок и т.п. Такое сканер пока что не может обнаружить, потому что здесь нужно знать контекст: что это за приложение и какие там могут быть угрозы. Таких вариантов может быть много и в других процессах так что нам всегда найдется, что делать.

То есть когда ты читаешь код, то проверяешь также все возможные варианты развития по какому-то процессу?

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

Если мы нашли уязвимость и хотим сообщить об этом, как заказчику наладить работу с такими сторонними исследователями безопасности?

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

А второе, если уже компания довольно большая и действительно думает о том, как сделать так, чтобы её продукты постоянно тестировали можно использовать Bug Bounty платформы, те же Hackerone и Bugcrowd. Суть в том, что компания договаривается с платформой, оговаривает скоуп ресурсов, которые будут исследоваться, принимаемые уязвимости и вознаграждение за них. В Bug Bounty участвуют уже много российских компаний Киви, Майл.ру, Яндекс. Можно посмотреть на их примере.

Что не стоит делать в таких случаях при работе со сторонними исследователями?

Я думаю, если вам написали, что у вас уязвимость, не стоит игнорировать такое сообщение. Лучше разобраться в проблеме и ответить.

А правда ли, по твоему опыту, что простые уязвимости самые страшные, а сложные никому особо не нужны?

Думаю, это не так, потому что обычно уязвимости оцениваются по тому, что с их помощью можно сделать. Например, с помощью уязвимости мы можем прочитать данные любого пользователя или получить исполнение команд на сервере и т.п. Чем больше потенциальный ущерб, который может принести эксплуатация уязвимости, тем она и ценнее, за нее больше заплатят на Bug Bounty. А уж сложная она или простая это другое дело. Но, конечно, если она простая, то, возможно, больше людей ее могут найти. И она этим страшнее. Может быть, пока ее обрабатывали на платформе Bug Bounty, уже кто-то из злоумышленников научился ее эксплуатировать. Но в целом, я думаю, что важен именно ущерб от уязвимости, а не простота или сложность.

То есть если большой ущерб ожидается от сложной уязвимости, ее все равно могут использовать?

Да, конечно. Из последнего здесь можно привести в пример довольно сложную цепочку уязвимостей в Microsoft Exchange под названием Proxylogon, которая, как известно, эксплуатировалась злоумышленниками.

А много ли тех, кто может самостоятельно найти новую уязвимость без использования готовых наборов или сканеров?

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

Какие уязвимости, найденные за твою практику, запомнились тебе больше всего?

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

Хоть это и не сильно относится к самому фреймворку, я все равно написал разработчикам. Меня порадовало, что откликнулись и исправили. Я как раз общался с Александром Макаровым, как одним из разработчиков фреймворка, и после того общения он пригласил меня выступить на конференции.

На конференции ты собираешься рассказывать как раз о безопасности в коде. Можешь рассказать об этом подробней?

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

А сам ты впервые выступаешь на конференциях, иди у тебя уже есть опыт? Тебе нравится?

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

И сам доклад получается по-настоящему классный.

Надеюсь, это будет полезно тем, кто прослушает доклад.

PHP Russia 2021 пройдёт в гибридном формате будет и офлайн, и онлайн. Онлайн-зрители смогут задавать вопросы спикерам в зале, принимать участие в дискуссиях и участвовать в активностях на стендах партнёров.

Мы с нетерпением ждём нашу встречу в офлайне 28 июня 2021 года. До 30 апреля стоимость очного участия составит 27 000 рублей

Подписывайтесь на наши соцсети, чтобы быть в курсе новостей (FB,VK,Telegram-канал,Twitter), общайтесь с коллегами в чате.

Генри Форд чуть не прогорел на своей классической фразе про пятьдесят оттенков черного. General Motors стала предлагать разноцветные модели Chevrolet, Pontiac, Buick, Oldsmobile и Cadillac и не прогадала. Глядя на это, даже упрямый Форд изменил свое мышление и разработал новый Ford A, вернувший его на автомобильный Олимп. Бывают времена, когда парадигма мышления должна стать новой ибо человек умирает тогда, когда перестаёт меняться Генри Форд.

Пришло время и для разработчиков. Command Query Responsibility Segregation (CQRS) и Event Sourcing (ES) уже не миф они реально работают. Конечно, не для всех задач как и классический черный цвет Форда, PHP никуда не исчез и нужен по-прежнему. Но теперь уже есть задачи, где мы встречаемся с CQRS и ES чаще, чем нам кажется. Антон Шабовта на PHP Russia 2021 расскажет, как смена парадигмы и взгляд с другой стороны помогают разработчикам. А перед конференцией мы расспросили Антона подробнее о его новых взглядах на разработку, PHP и, конечно, оCQRS и ES.

Антон, расскажи о себе и о своей работе. Чем ты занимаешься?

Последние 12 лет я в коммерческой разработке и большая часть времени занимался проектами связанными с E-Commerce. Но 3 года назад мне захотелось применить свои знания в проектах другой сферы. Так я пришел в сервисную команду Onlinerа это крупнейший белорусский медиа портал с огромным количеством сервисов. Нашу команду разработки можно условно разделить на две части. Команда каталога занимается основном продуктом каталогом товаров. В нем почти два миллиона позиций от тысяч магазинов а это десятки миллионов товарных позиций. И этот действительно большой и сложный E-Commerce продукт, который продолжает развиваться и расти.

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

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

Твой доклад на конференции будет про долгий путь к CQRS и Event Sourcing. Это связано с твоей карьерой разработчика?

Да. Впервые я столкнулся с подходами Command Query Responsibility Segregation (CQRS) и Event Sourcing (ES) еще при работе с E-Commerce в 2015 году. И это стало важной вехой в моей карьере разработчика. Информации о CQRS и ES было много, но столько же возникало вопросов, мифов и недопонимания. Что именно представляют собой эти технологии? Как их использовать? Где стоит применять и какие проблемы они действительно призваны решать? Так вот одна из моих целей на PHP Russia 2021 развенчать часть этих мифов и показать, что мы сталкиваемся с CQRS и ES намного чаще, чем кажется, даже если раньше мы никогда не слышали эти слова.

В 2017 году, проработав два года с CQRS и ES, я сделал доклад об этом в рамках митапов Минской PHP User Group. Но, пересмотрев слайды, я понял, что в корне неверно подходил к объяснению этих технологий. За пять лет мое понимание значительно преобразилось, и я надеюсь, что на этот раз смогу лучше объяснить. Так что во многом доклад для PHP Russia 2021 это еще и работа над ошибками.

У тебя есть опыт с Erlang и Java (про С/С++, C# и Python знаем), или же ты целенаправленно изучаешь практики оттуда, чтобы рассмотреть их для PHP?

По-разному, it depends. Исторически так сложилось, что многие книги по архитектуре программных систем используют примеры и понятия из Java-мира. И чтобы не упустить какие-то ключевые моменты и важные нюансы, пришлось разбираться в Java. Недавно стряхнул пыль с этих знаний, когда искал решения для своих проектов и разбирался с фреймворками Axon и Akka. В целом же, практики из одного языка, по крайней мере, из Java, очень легко и просто переносятся на PHP.

С# я начал изучать, когда разбирался в устройстве фреймворка NServiceBus. В нем реализовано много классных решений, связанных с MBA (message-based architecture), SOA (service-oriented architecture) и сопутствующими технологиями.

Erlang это вообще отдельная история. Интерес к нему пришел в процессе изучения классического понятия ООП (объектно-ориентированного программирования) от Алана Кея и модели экторов. Это реально классный язык, совершенно непохожий на другие. Не могу сказать, что готов сейчас писать на нем production ready код, но изучать его концепции, конечно, продолжу.

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

Не всегда то, что успешно работает в одном языке, будет работать в другом. Но в процессе изучения я вижу, когда какие-то практики можно попробовать.

Помогает ли знание других языков лучше писать на PHP?

И да, и нет. С одной стороны, многие практики и идеи можно (и нужно!) применять в PHP, особенно из близких по духу по подходам языков (Java, C#). ООП-модель PHP очень близка к этим языкам. К тому же мир разработки в PHP очень сильно изменился, например, после выхода фреймворка Symfony 2. Команда Symfony проделала колоссальную работу по прививанию паттернов проектирования в PHP community. Но большинство паттернов были придуманы не для PHP, а для других языков, в том числе, для Smalltalk и Java.

С другой стороны, из-за технических ограничений, некоторые интересные концепции невозможно развивать и применять в PHP. Например, многие подходы из мира функционального программирования и модели экторов, пропагандируемые Erlangом. Мы ограничены технологиями своего времени. Но, возможно, часть этих технологий в будущем можно будет применить и в PHP.

Когда нужны подходы из других языков, а когда лучше по старинке или попроще?

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

Я стараюсь для себя придерживаться KISS-принципа, то есть Keep it simple, stupid: если есть возможность делать что-то проще и не усложнять, то лучше так и сделать. Такие серьезные подходы как CQRS и ES несут много изменений не только в коде, а даже в самой модели мышления программиста. Мы ставим себя в определенные рамки, и за это придется платить. Не бывает серебряной пули в программировании.

Поэтому внедрять CQRS и ES не глядя, просто потому что можем очень-очень плохая идея. Можно получить намного больше проблем, чем пользы. Конечно, когда-то это оправдано, но не всегда. Поэтому нужно хорошее изучение problems face, чтобы понимать, зачем мы внедряем эту технологию и какую проблему бизнеса пытаемся ею решить.

Что дают эти подходы разработчику, в чем помогают?

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

Поэтому нет популярных фреймворков для CQRS и ES?

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

С другой стороны, ES и CQRS неразрывно связанны именно с моделированием домена приложения, то есть это доменная модель. А хорошая доменная модель не должна зависеть от фреймворка. Но мы можем ее внедрить в любой фреймворк, с котором нам удобно будет работать.

Создатель этих подходов Грег Янг любит повторять в своих докладах, что для реализации ES и CQRS достаточно двух операций:

1. Сравнение по образцам (pattern matching);

2. Лево-ассоциативная свертка списка (left fold) функция высшего порядка.

И многие языки поддерживают эти операции уже на уровне стандартной библиотеки. Например, тот же left fold в PHP существует как array_reduce, и дополнительно можно придумать другие варианты реализации.

Pattern matching, к сожалению, полностью в PHP еще не реализован, хотя работа в этом направлении ведется. Но та малая часть из pattern matching, которая нужна для имплементации ES, легко эмулируется в user-land коде.

Есть также много технологий, которые работают вокруг и рядом с CQRS и ES те же message-based architecture и service-oriented architecture. Для этих технологий уже есть фреймворки, хотя достаточно популярных в PHP-мире пока не сформировалось. Какие-то работы сейчас ведутся и какие-то фреймворки вырастают. Но enterprise production ready, решений уровня того же NServiceBus в C# либо Axon в Java, пока в PHP не сложилось. Ждем!

А есть ли учебник, где на пальцах правильно объясняются эти подходы?

Изучать CQRS и ES стоит с просмотра докладов отца-основателя Грега Янга, с его публичных выступлений, статей, материалов и записей в блоге. Он подробно пишет, как он пришел к этим подходам, и из каких проблем они возникли. Для продолжения есть его книга Versioning in an Event Sourced System там вы найдете для себя кое-какие нюансы.

Много материалов по ES и CQRS подходам можно найти в документации Microsoft. У них есть даже более развернутый вариант, который вышел в виде отдельной книги Exploring CQRS and Event Sourcing. Предисловие к книге написал тот же Грег Янг.

Еще этим технологиям много внимания уделяют те, кто пишут и работают с DDD-подходом (Domain-Driven Design), например, Vaugh Vernon. И у него есть книга Implementing Domain-Driven Design, в которой большая глава посвящена именно ES и CQRS.

Кому можно верить, не проверяя, в мире разработки и PHP: Фаулеру, Мартину, кому-то еще?

Никому. Серьезно. Мартин Фаулер, Роберт Мартин, тот же Грег Янг, а также другие авторы тратят сотни часов времени, чтобы поделиться своими знаниями в статьях, в записях блогов, в докладах и в книгах. Иногда пишутся целые научные работы по каким-то подходам. Это действительно круто, что мы имеем доступ к этой информации.

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

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

То есть ты сам не придерживаешься этого всего?

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

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

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

Чего ты ждёшь от конференции в этом году?

Онлайн-формат это, конечно, интересно и круто. Но пока я не могу сказать, что он может заменить оффлайн. Поэтому в первую очередь я жду, конечно, отличных докладов, много профессионального общения и интересных обсуждений в кулуарах. Я считаю, что эти обсуждения даже более ценны, чем доклады. Зажав спикера в кольцо, можно ему задать важные вопросы, которые не всегда есть время раскрыть в докладе. Очень часто какие-то действительно problem spaces остаются за рамками докладов.

Еще я жду новостей! С такими переносами, я думаю, к моменту начала конференции у нас их будет немало. Хотелось бы знать:

• Что нас ждет в PHP 9?

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

• Вопрос, волнующий всех: появятся ли у нас Generic-типы? Недавно добавили Union-типы. Скорее всего, скоро добавят пересечения, но Generic это то, что возникает так или иначе в вопросах на каждой PHP-конференции.

И афтепати, конечно!

PHP Russia 2021 пройдёт в гибридном формате будет и офлайн, и онлайн. Онлайн-зрители смогут задавать вопросы спикерам в зале, принимать участие в дискуссиях и участвовать в активностях на стендах партнёров.

Мы с нетерпением ждём нашу встречу в офлайне 28 июня 2021 года. Сегодня последний день до повышения цены сейчас стоимость очного участия 27 000 рублей

Подписывайтесь на наши соцсети, чтобы быть в курсе новостей (FB,VK,Telegram-канал,Twitter), общайтесь с коллегами в чате.

Одно дело почитать теорию об уязвимостях и совсем другое увидеть последствия и защититься на практике. Специалист по защите приложений в DINS Иван Юшкевич предлагает испробовать это во время конференции PHP Russia 2021, где он представит свой практический доклад Веб-безопасность для начинающих.

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

Расскажи о себе и своей работе, чем ты занимаешься?

Я специалист по защите приложений. Занимаюсь ApplicationSecurity в компании DINS. В этой области я уже лет десять. Начинал как специалист по защите информации, потом занимался тестированием на проникновением.

Что планируется на конференции и почему именно такая тема доклада?

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

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

На конференции я расскажу, почему prepared statements только усложняют код, а возможность внедрения JavaScript-кода на сайте не является багом. Кроме того, на практике мы с участниками попробуем накрутить лайков в социальных сетях, украдем криптовалюту и получим доступ к самым большим секретам пользователей. А потом я объясню, что нужно делать, чтобы не допустить подобных случаев в веб-приложении.

Как ты думаешь, кому будет полезен твой доклад?

1. Узнает ли, например, сеньор что-то новое, если он пойдет на этот доклад? Нет.

2. Узнает ли что-то миддл? Вполне. Возможности, ничего нового в инструментах он и не узнает, но может задуматься над некоторыми аспектами безопасности.

3. Узнает ли что-то джун, который пойдет на доклад? Абсолютно точно.

Почему так? Потому что есть более интересные доклады для сеньоров. Что-то небанальное, о том, как построить самолет из желудей и спичечных коробочек. А для миддла написание кода одна из актуальных задач.

Программисту действительно нужна практика в вопросах безопасности? Если да, то зачем?

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

В чем профит для разработчика? Ведь у компании куча денег, зачем ему их считать? Он может расширить свои компетенции и в некоторых случаях претендовать на звание Security Champion в компании.

Что нужно сделать, чтобы стать специалистом в твоей области? Пройти обучение и стать сертифицированным специалистом, или есть другой путь?

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

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

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

Как можно убедить бизнес уделить время вопросам безопасности? Какие ты слова подбираешь для того, чтобы этого добиться?

Слова очень простые. Причем, не мои, эту мысль озвучили уже до меня: исправление уязвимости на этапе разработки стоит около ста долларов, а исправление уязвимости в выпущенном продукте на порядки дороже. Вот и все.

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

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

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

Достаточно ли сделать один раз аудит, или нужно выстраивать процесс внутри компании?

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

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

Считаешь ли ты свой доклад нетривиальным?

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

PHP Russia 2021 пройдет 28 июня вМосква, Radisson Slavyanskaya. Но уже сегодня можно ознакомиться с расписанием и присмотреть доклады, которые вы точно не захотите пропустить.

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

Как считает Евгений Россинский, СТО должен быть одновременно и стратегом в настоящем, и мечтателем, смотрящим в будущее. Стратег должен очень хорошо понимать, где находится сейчас чтобы что-то улучшить, надо сначала померить и найти метрику качества. А мечтатель должен любить свое дело, чтобы заряжать людей вокруг и двигать дело вперед.

Евгений основал компанию по разработке высоконагруженных проектов Netstream (online-вещание и видео), а в 2012 году вместе со всей командой перешел в ivi, где является СТО до сих пор. C 2006 года преподает в МГТУ им. Баумана авторский курс Технологии командной разработки ПО, потому что однажды обнаружил, что не может найти грамотных разработчиков в команду.

Такой же стиль у него в Программном комитете HighLoad++ находить интересных спикеров и животрепещущие темы, чтобы показать их широкой аудитории и продвинуть в будущее. Накануне конференции мы встретились с Евгением, чтобы расспросить о докладах и спикерах HighLoad++ Весна 2021. Что было бы интересно, а что просто обязательно надо идти и слушать, если вы разработчик высоконагруженных систем.

Женя, расскажи, чем ты занимаешься и какое отношение имеешь именно к высоким нагрузкам?

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

Какие доклады HighLoad++ ты курируешь как член Программного комитета?

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

Тебе нравится быть в ПК? Что это для тебя?

Да, мне нравится. Это прекрасное времяпрепровождение по четвергам вечером :)

Но на самом деле это дает много возможностей.

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

Ты сам часто бываешь на конференциях?

На наших да. На HighLoad стараюсь попасть, но даже если не попадаю, всегда смотрю интересные доклады в записи. Некоторые вещи даже пересматриваю и делаю себе пометки.

Но офлайн круче онлайна?

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

Я и выступать онлайн не люблю, потому что ты не понимаешь аудиторию. Говорить в монитор можно 5 минут или даже 10. Но за 40 минут, пока что-то рассказываешь, ты знать не знаешь может, все уже ушли кофе пить, а ты распинаешься. Я предпочитаю видеть аудиторию. Поэтому я за то, чтобы люди приходили и смотрели офлайн. Плюс я считаю, что конференция хороша, когда это совместная работа с обеих сторон и докладчиков, и слушателей которые к тому же находятся в одном помещении. Когда ты пришел, тебе уже, черт возьми, неудобно перед человеком, который стоит на сцене! Ты, конечно, в телефончике можешь что-то тыкать, но общий коэффициент полезного действия от слов докладчика сильно выше.

Как часто ты сам выступаешь?

На HighLoad я выступал последний раз в 2018 году, и у меня было 3 доклада. Пару раз был спикером на TeamLead Conf. А сейчас у меня пока нет таких вещей, которыми хотелось бы похвастаться. Можно, конечно, из пальца высосать какую-то тему. Даже она кому-то будет интересна потому что всегда найдутся люди, у которых нет твоего опыта и твои слова будут им нужны и интересны. Но хочется же, чтобы доклад нравился самому себе.

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

Как построить доклад, чтобы выступление было запоминающимся и интересным? Какие-то фишки есть у тебя?

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

В целом же ты должен понимать запросы аудитории, чтобы предложить конкретный практический опыт в том, о чем говоришь. Тогда можно привести примеры, которые зайдут аудитории и люди поймут, зачем им это нужно. Важно говорить на одном языке с аудиторией. И подсвечивать, не скрывая, проблемы, которые были у тебя. Есть доклады: У нас было все прекрасно! Сейчас мы сделали все еще более замечательно! но так не бывает. У всех всегда есть большая бочка дегтя и всего одна ложка меда, а все только про нее и рассказывают. А самое важное это как раз то, как бочку расхлебать.

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

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

Что же ждет нас в этом году на HighLoad++ 2021?

Подготовка к HighLoad++ Весна 2021 из-за пандемии безумно растянулась во времени. Но зато и программа получилась плотная, классная. Сейчас самое время обкатать все сложившиеся темы, даже если некоторые подустарели за полтора года.

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

Хороший доклад от Ozon про Data Management Platform. Будет интересно узнать, как ребята автоматизировали фильтрацию пользовательских событий. Сама тема мне тоже довольно близка, поэтому я с удовольствием послушаю.

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

Также всегда очень интересно послушать Андрея Аксенова даже когда он несет какую-то дичь, все равно это интересная дичь. В этот раз у него будет прикладная эзотерика. Хочу это послушать, потому что 80% его докладов фееричные. Ну и просто интересно узнать, что у человека в голове.

Доклад Погружение в Helm package manager пришел к нам по рекомендации, и после проверки тоже вошел в программу. Олег Вознесенский из X5 Retail group расскажет про Helm. Это как раз тот случай, когда мне интересно послушать конкретные use case и какие-то вещи, которых в документации нет, а человек уже их попробовал и у него есть экспертиза. И Олег очень просто и на пальцах объясняет те штуки, которые надо долго пробовать, чтобы накопить эту экспертизу.

Также всегда приятно послушать Алексея Миловидова. Он говорит про интересные вещи, которые иногда становятся основой для философии. К тому же мне очень интересно всё, что касается ClickHouse. В ivi мы его применяем тоже, и поэтому эта тема всегда очень острая для нас.

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

Денис Рожков и Георгий Тарасов в Информационной безопасности против HighLoad раскроют нужную и одновременно интересную тему про кибербезопасность. А Mail.ru расскажет историю про версионирование данных на Tarantool.

А еще Саша Тоболь! Мой хороший друг, прекрасный инженер, который великолепно рассказывает, прекрасно разбирается в материале и всегда очень глубоко погружается во все темы. Саша бывший лид Одноклассников, а сейчас СТО в ВК. Его всегда классно послушать, у него редкое сочетание, когда и докладчик хороший, и инженер классный.

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

В общем и целом какие боли затрагивает эта конференция и чем она поможет слушателям?

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

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

Последний вопрос: что HighLoad лично для тебя?

Сначала это была просто тусовочка, а сейчас это работа, хобби, увлечение и сообщество.

HighLoad++ довольно интересная конференция, которая позволяет тебе посмотреть на свои проблемы под другим углом. Ты, может, и не найдешь решения своей конкретной задачи, но другие use cases могут тебя подтолкнуть на идеи, что можно еще и по-другому сделать. И в том направлении, о котором ты совсем не думал. Это и ценно в любой конференции. На HighLoad у меня было много таких открытий.

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

С каким настроением идти на HighLoad++?

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

КонференцияHighLoad++ Весна 2021уже готовится к посадке 17 и 18 мая в Москве в Крокус-экспо мы все встретимся и обсудим всё то, что невозможно было обсудить в чатиках. Расписание ждет вас, а там в течение всех двух дней 8 потоков выступлений, 6 мастер-класов и пивная вечеринка!

Билеты можно купитьздесь. А подписавшисьна нашу рассылку, можно получить материалы мини-конференции Saint HighLoad++ 2020 :)

Возможно, вы уже умеете писать отличный код. И может, у вас уже есть реальное представление, как работает платформа, виртуализация и сеть с безопасностью. Но что, если вы не хотите углубляться ни в одну из этих областей? А может, вы уже думали о переходе в DevOps, где требуется много знаний и со стороны dev, и со стороны ops, но не нужно становиться хардкорным разработчиком? Тогда у нас хорошая новость начинать в DevOps можно в любом возрасте и с любой технической специализацией.

Тому пример Александр Шуляк, который нашел себя именно в Девопсе. Накануне конференции DevOps 2021 мы встретились с Сашей и поговорили о том, как и с чего начался его DevOps, а также к чему он пришел в этой карьере.

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

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

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

Как ты узнал про DevOps?

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

В результате мне повезло оказаться единственным DevOpsом в аутсорсе средних размеров. Меня сразу же отправили на амбразуры проектов и заказчиков. Это было безумно стрессово, но очень эффективно я учился очень быстро, буквально на ходу.

Какие твои навыки тебе тогда потребовались на практике?

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

Тогда от меня требовалось писать код, чтобы автоматизировать всё и вся. При этом нужно было ковыряться в системах, но уже абстрагируясь от железа. Использовать облачные ресурсы, чтобы быстро получать требуемые мощности.

В DevOps пригодятся любые навыки программирования, и начальный язык не так важен, потому что пересесть на профильные python/golang не будет сложным делом.

Что именно нужно уметь кодить DevOps-инженеру?

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

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

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

Shell-скрипты это ведь часть работы в терминале. Что-то еще там нужно уметь?

В терминале вы будете проводить большую часть своего рабочего времени, потому что вся отладка, да и значительное количество инструментов текстовые. Нужно уметь работать в терминале быстро. Очень помогают навигация, редактирование конфигов, знание базового набора утилит и интерпретаторов. В процессе дебага надо знать, как быстро получить нужные значения параметров системы, открытые сетевые соединения и т.д. И очень важно уметь работать с самим текстом, фильтрами и регулярными выражениями. Awk - страшная вещь, но иногда очень спасает.

Какие инструменты нужно изучать для мониторинга и сбора логов?

Основные инструменты для сбора метрик сейчас это Prometheus и Grafana. Prometheus это метрик-коллектор (формально time-series database). Как альтернатива мне ещё очень нравится TICK стек на базе InfluxDB. Grafana, в свою очередь, используется для отрисовки красивой инфографики и отправки оповещений.

Для сбора логов в одном месте можно посмотреть Elastic Stack. Он довольно сложный, но дает отличное представление о работе с логами. У него есть бесплатная версия, и этого достаточно, чтобы поиграться с системой и понять, как она работает, из каких компонентов состоит. Альтернативы Elastic Stack Splunk, Datadog. Но это больше enterprise-инструменты, изучать их достаточно сложно.

Что насчет операционных систем? Чем тут заняться, чтобы приблизиться к девопсу?

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

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

У Linux Professional Institute (LPI) есть статьи по работе linux и базовым манипуляциям с системой. Это открытые курсы/уроки, и они хорошо помогут разобраться с работой Linux. А у Роберта Лава (Robert Love) есть отличная, хоть и немного скучная книга Ядро Linux: описание процесса разработки. Помогает быстро уснуть :)

Ещё в изучении Linux вам может сильно помочь Youtube-канал Кирилла Семаева.

Поговорим про сетевую сторону operations. Что нужно уметь делать здесь?

Первое и самое важное знать как работает сеть. Теоретическая и практическая часть прекрасно описаны в цикле статей от linkmeup сети для самых маленьких. Статьи на примере Cisco, с прекрасными иллюстрациями и отличными объяснениями. Очень легко понять, как сеть работает на всех уровнях.

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

Расскажи про принципы DevOps. Это что-то as Code. Как они работают?

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

Наверное, самый популярный инструмент управления инфраструктурой (Infrastructure as Code) это Terraform. Его довольно просто изучать, там великолепная документация. И буквально в этом году вышло новое издание книги Евгения Брикмана Terraform. Инфраструктура на уровне кода, которая тоже отлично объясняет, как работать с этим инструментом.

Есть ещё принцип Configuration as Code, который описывает состояние операционной системы. Тут я советую для изучения Ansible. Можно Chef, но выбрать можно любой, так как поняв основной принцип работы одного, переходить на другие инструменты будет несложно.

А Pipeline as Code вообще очень интересная вещь. Так как синтаксис и предоставляемые возможности инструментов очень схожи, то можно спокойно выучить один и пользоваться всеми. С другой стороны, практически всегда построение пайплайнов приводит к shell-скриптам, потому что основного инструмента без его кастомизации в любом случае будет недостаточно.

Оркестрация это тоже необходимый навык?

Да, примерно по тем же причинам, почему мы используем всё as Code. Когда у вас контейнеров больше одного, ими сложно управлять. Для этого и существуют оркестраторы вроде Mesos, Nomad, Openshift, Kubernetes и так далее. Самый популярный, конечно, Kubernetes. Он достаточно сложный для изучения с точки зрения архитектуры и управления, но базовые понятия выучить не проблема. На первых порах этого должно быть достаточно, а остальное придёт с опытом и интересом.

Какие есть особенности у специализации DevOps-инженеров?

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

На практике список обязанностей сильно зависит от размера компании. Где-то могут быть большие команды и несколько DevOps-инженеров, которые отвечают за build продукта, релиз, платформу или безопасность и governance облака.

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

Так я оказался в Лондоне. Сейчас, после полутора лет в Gearset, я Senior SRE в финтех-стартапе Divido. И мой опыт показывает, что в Англии больше верят в узкую специализацию, чем у нас. То есть вам надо знать некоторые предметные области в вашем техническом стеке намного лучше, чем другие. Допустим, если вы Cloud Ops инженер, то у вас будет сильный упор на бизнес-инструменты именно в облаках.

У нас же чаще подразумевается, что человек умеет делать всё.

Твой доклад как раз по этой теме?

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

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

Что ты предпочитаешь, офлайн или онлайн?

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

Какие темы из программы для тебя наиболее актуальны и какие доклады хочешь послушать сам?

Разумеется доклад Дмитрия Столярова, я его большой фанат! :) У него всегда можно узнать что-то новое про кубер, с которым я последние два года очень плотно работаю. А также о теоретической части SRE/DevOps, поскольку мне очень интересно, как выстроены процессы в разных компаниях и как они скрещивают методологии с реальной жизнью.

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

Ну и конечно, нас ждет извечно актуальная и холиварная для меня тема про SRE человек-оркестр, потому что никто не знает как обозвать человека со специфичным набором навыков и вообще надо ли :)

Саша, спасибо тебе огромное за подробный разговор. Желаем тебе найти билеты в Россию, чтобы встретиться на конференции!

Спасибо и до встречи!

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

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

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

Но как часто мы обсуждаем наши повседневные инструменты с точки зрения читабельности, хотя пишем под web и каждый день используем консольные утилиты? Сегодня Андрей Светлов расскажет, что со всем этим делать, и чем он пользуется для консолей. Помимо того, что Андрей CPython Core developer и понемногу развивает Python, в свободное от работы время он эксперт по asyncio, со-автор aiohttp, yarl, multidict и прочим популярным библиотекам.

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

Информативность

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

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

Размер шрифта и экрана

Снова тот же Docker. Если экран не очень широкий, если шрифт большой или вертикальный экран, то Docker перестает помещаться и выводится на две строки:

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

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

Scrolling & Pager

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

Светлый/темный цвет фона

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

Что из этого следует? Возвращаемся к примеру от Github. Вот вывод команды (неважно какой, сейчас это статус моих pull requests) на темном фоне:

И он же со светлой схемой:

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

ЦВЕТА И СТИЛИ

Все, что мы можем использовать, чтобы не рябило в глазах пяток цветов и еще несколько стилей:

На этом выбор цветов для нас закончен! Конечно, такая очень узкая палитра не позволяет использовать полноцветные терминалы и точно перенести всё, что ваш UX дизайнер нарисовал в Фотошопе. Но зато у нее есть одно чудесное свойство: если приглядеться, то видно, что, например, желтый это не классический желтый, а немного золотистый, чтобы выглядело хорошо. И все цвета подобраны программой терминала так же. Если меняется тема, то программа снова подскажет, как правильно, хорошо, контрастно и красиво нарисовать этот цвет для терминала.

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

Обычно мы, конечно, выбираем понятные всем цвета:

• Зеленый все хорошо;

• Красный плохо;

• Желтый warning.

Но если хотим большего, у нас есть подсказка для команды LS есть соглашение, каким цветом мы будем выводить файлы и папки. Это обеспечивается двумя переменными среды. Первая исторически появилась в виде LSCOLORS и рассказывает, как рисовать файлы и папки: по две буквы на одну позицию. Позиция это папка (нормальный файл, сокет, что-то еще). В документации или в интернете это всё есть. Первая буква отвечает за цвет шрифта (букв), вторая за цвет фона. Я попытался раскрасить так, как у меня закодировано на моей рабочей станции

Второй вариант немножко похитрее: помимо обозначений для папок и символических ссылок, можно еще рассказывать, какие окончания файлов рендерить:

И если у вас вывод, похожий на файлы, и там можно применить эти цвета, стоит написать простенький парсер и самому отформатировать вывод. Достоинство всё то же: эти цвета для LS настроены темой вашего терминала. В терминале они выглядят хорошо, естественно, сбалансировано и ваша программа при их использовании будет выглядеть так же.

Смайлики

Смайлики нельзя недооценивать, это очень хорошая вещь простенький значок, но позволяет быстро сориентироваться на экране:

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

Поэтому выбирайте простые символы, смотрите, как они рендерятся в разных режимах и проверяйте это на всех платформах (Windows, MAC, Ubuntu). И математические символы в том числе. Везде есть хитрые смайлики, с которыми могут быть проблемы.

Shell

Еще нужно помнить, что терминал существует не сам по себе. Консольные программы, в нем запускаются под разными shell: sh, bash, zsh, fish, cmd.exe, powershell или еще какие-то. Программа должна работать с выбранным shell без проблем, в том числе на Windows. Но на практике мы видим разницу в том, как shell авто-дополняет ввод и как (и в каком терминале) выводятся символы. Поэтому проверяйте и на своем shell, и на тех, которые будут у пользователей.

TTY навсегда?

Помимо shell и интерактивного режима, на который в консолях тратится большая часть усилий по пользовательскому дизайну, программы у нас могут запускаться и без терминала. И когда мы, например, перенаправляем вывод через py в grep, чтобы что-нибудь там поискать, или записываем в файл, или запускаем из-под cron, HTTP-сервера или еще чего-нибудь функция os.isatty() будет возвращать false:

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

Windows, любовь моя

К сожалению, мир консольных программ делится не только на темный и светлый фон, а еще на Windows и всех остальных. Если на posix системах (тех же MAC и Linux) всё весьма похоже, то на Windows есть много отличий, например:

• less more. Стандартная прокрутка less отсутствует, вместо нее есть куда более гадкое и неудобное more.

• \n \r\n. Возврат каретки другой.

• dim / gray. Серого цвета нет (но на MAC, кстати, тоже бардак по поводу цвета, поэтому и надо всё проверять).

• ANSI escape символы, которые как раз делают расцветку и прочие полезные вещи, по умолчанию выключены, но это легко поправить.

• -\|/. Многие символы, как я говорил, не работают. Например, здесь наш специалист по UX создал дизайнерский спиннер у нас он должен крутиться треугольниками, а не палочками, как у всех остальных. Почему бы и нет? Но на Windows он крутится одинаковыми квадратиками, то есть не работает.

Инструменты

Расскажу теперь, какими чудо-инструментами можно (и нужно) пользоваться при создании консольных программ и их интерфейсов. Некоторые инструменты действительно чудо там и молоток есть, и напильник, иногда и кувалда встречается. Единственный нюанс. Так как консольная утилита вещь маргинальная и нишевая, ее разработчики создают сами для себя, то инструментарий может быть не таким классным, каким бы он мог быть, и не таким доведенным до ума, как для web-программ, например.

CLICK

Я очень рекомендую Click от славного парня Армена Ронахена. Это инструмент со своими особенностями, но он гораздо лучше и мощнее, чем встроенный в Python argparse. Если вы сомневаетесь, используйте Click.

В нем есть набор утилит (функций), чтобы выводить тексты со стилями можно печатать или накладывать стиль, чтобы получилась строка с анти-последовательностями. Можно снимать стили, использовать pager:

Кроме того, у Click есть маленькая, но очень приятная и удобная фича он автоматически убирает стили для не-терминала (non-TTY). Click сам понимает, когда вывод идет не на полноценный терминал, а, например, куда-нибудь в файл он автоматически снимает все стили и делает click.unstyle. Конечно, вы можете сделать unstyling сами, вместо использования click. Но в любом случае избегайте перенаправления в файл покореженного текста с кучей непонятных значков.

PYTHON PROMPT TOOLKIT

Второй инструмент чудесная штука, которая используется, например, в IPython, BPython, в других shell это инструмент для создания полноценных приложений. Но нас сейчас интересуют вопросы ввода-вывода и здесь Prompt Toolkit решает все вопросы.

Сначала мне показалось, что Prompt Toolkit избыточен потому что для работы хватает и Click. Например, если нужен progressbar, есть всем известный tqdm. Великолепная библиотека, которая решает ровно одну задачу, но делает это хорошо. А еще есть и click.progressbar().

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

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

Благодаря слоям, в Python Prompt Toolkit можно легко отрисовать несколько progressbar-ов по одному на слой загружаемого образа таких же, как например, делает Docker pool:

ВСЁ ПРОПАЛО, ШЕФ! ИЛИ "ГДЕ МОЙ КУРСОР?"

Мелочь, которая в свое время попортила мне немало крови.

Распространенная тема: есть консольная программа, которая рисует чудесные виджеты, рассказывает, как Docker Image тянется на много потоков, даже не моргает и отрисовывает всё гладко. Но если ее внезапно закрыть, может, например, пропасть курсор потому что в последнем режиме курсор спрятали, а обратно не вернули. Бывает, что вы в терминале печатаете, а курсор не мигает на экране. Есть и более сложные способы испортить консоль, загнав ее в какой-нибудь режим, который не предназначен для интерактивного вывода.

Чтобы этого не было, основная программа при выходе должна напечатать магическую скрипт-последовательность на экран:

Это так называемый Soft Reset, который сбрасывает режимы. Например, тот же less умеет переключаться для полноэкранного скроллинга в альтернативный режим. Но если ваша программа пытается реализовать функциональность как old less, то без магического скрипта при выходе надо будет переключаться обратно вручную.

ASYNCIO + CLICK

Я не могу не рассказать про asyncio!

Но Click из коробки не работает с asyncio от слова совсем! Он это не умеет, он написан немного раньше, и они совсем не дружат. Поэтому самым простым решением будет написать AsyncioRunner(), который будет не функцией, а классом, а run можно вызывать несколько раз. Это бывает удобно, например, когда запускаем асинхронный код для проверки типов входных параметров и вдобавок что-то еще run запускаются друг за другом в одном и том же контексте:

И что важно AsyncioRunner() работает при этом как асинхронный контекстный менеджер, то есть по завершению работы чистит за собой.

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

ASYNCIO + PROMPT_TOOLKIT

А вот Asyncio + Prompt_Toolkit работают вместе великолепно даже из коробки. Prompt_Toolkit знает об asyncio, а Prompt_async это стандартная штука Prompt_Toolkit, которая и запускает основную программу. Детали читайте в документации:

WINDOWS не отпускает

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

Давно известный проект Colorama работает почти со всеми escape-последовательностями, подменяя собой stdout и stderr. Он парсит то, что печатается, находит там escape-последовательности и убирает их. Вместо этого вызываются разные Windows-функции для того, чтобы поменять тот же самый цвет букв или цвет фона. Но Colorama работает только с подмножеством ANSI-символов.

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

Но, к счастью, сейчас наступила эпоха Windows 10. К счастью, потому что в ней можно перевести экран в режим, который обрабатывает escape-последовательности (по умолчанию он не включен). Этот режим позволяют включить две простые функции, вызвать их из Python при помощи ctypes это упражнение на пару минут:

АВТОЗАПОЛНЕНИЕ

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

Здесь декоратор принимает click.argument от autocompletion то есть функция вызывается тогда, когда в процессе вывода мы нажимаем табуляцию, как обычный Bash, а еще лучше Zsh как это делают shell для большого количества команд.

ВАЛИДАЦИЯ

В Click, разумеется, есть стандартные типы чисел, дат и файлов. Но если хочется сделать нестандартный тип, например, URL, то мы можем написать класс для параметра (будем его указывать в аргументе или опции), и Click автоматически вызовет метод convert, давая возможность нашему коду проверить, преобразовать тип и т.д.:

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

Общепринятые мировые практики против проведения нескольких трансформаций в компании одновременно. И все же они возможны, при соответствующей подготовке, привлечении необходимых ресурсов и правильном мониторинге результатов. Плюсами и минусами одновременных трансформаций на конференции DevOps Live 2020 поделился лидер трайба IT4IT в ОТП Банке Максим Ефимов.

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

Как происходит любая трансформация в крупной организации?

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

Впереди перемен Джона Коттера мировой бестселлер, который может стать настольной книгой любого лидера трансформации.

Accelerate это произведение о том, как инженерные практики и DevOps культура меняются сами, меняют организации и бизнес, увеличивают performance и profitability любой организации.

Team topologies рассказывает о практиках организации взаимодействия между командами.

Основная мысль, которую можно вынести из книги Впереди перемен, это:

Никогда нельзя делать несколько крупных глобальных изменений одновременно.

Это анти-паттерн того, как выполняются трансформации, потому что такие действия влекут за собой:

• Гораздо большие риски;

• Размытие фокуса;

• Выгорание сотрудников;

• Взаимное негативное влияние трансформаций.

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

Кроме того, трансформации могут иметь негативное влияние друг на друга. И занимаясь, вроде бы, хорошими делами, вы в конце концов приходите к отрицательному результату.

Трансформация в ОТП

Предпосылки для начала трансформации в ОТП были серьезными: процессы критично устарели и усложнились, а TTM был очень низким (4 релиза в год).

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

И в ОТП решили сделать все и сразу:

• Изменить оргструктуру, перейти к Spotify-модели и внедрить продуктовые трайбы;

• Создать институты чаптеров и гильдий;

• Сфокусироваться на продуктовой разработке и поменять процессы IT;

• Провести редизайн IT ландшафта и модернизацию IT;

• Внедрить DevOps и автоматизацию;

• Кардинально привязать работу к облакам и микросервисной архитектуре.

Обсудим подробнее, что произошло по каждому из этих пунктов.

Трайбы и оргструктура

В ОТП запустили трайбы, отказались от линейной подчиненности и ввели матричное подчинение.

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

Трайб состоит из нескольких команд. У каждой из них есть product owner и бизнес-эксперты.

В ОТП есть своя особенность: в их командах нет выделенных DevOpsов и QA, это роли, которые выполняют разработчики.

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

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

Важный нюанс: в компании хотели, чтобы люди переопылялись не только внутри трайба, но и кросс-трайбово. Для этого был запущен институт гильдий. Разница между подходами в том, что участие в трайбе условно обязательно. Если вы бэкенд-разработчик, то попадете к сеньору Васе в чаптер бэкенд-разработки, трайба 1. Гильдия это сообщество, можно сказать, кружок по интересам.

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

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

Продуктовая разработка и изменение IТ процессов

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

Было важно организовать взаимодействие между всеми этими командами так, чтобы:

1. Продуктовые команды могли вносить изменения в функционал CORE систем;

2. Эти изменения не влияли негативно на стабильность в CORE системах;

3. Сохранялся необходимый темп доработок.

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

IT модернизация и редизайн IT ландшафта

Для того, чтобы все вышеописанное стало возможно, в ОТП решили создать слой API вокруг CORE систем.

Например, есть платформенная команда, развивающая сервис В. Она, посредством API, взаимодействует с сервисом А, который развивает продуктовая команда. В ОТП выработали стандарт, проясняющий, каким образом можно делать интеграции, как они должны работать и как организовано синхронное/асинхронное взаимодействие.

DevOps и автоматизация IT4IT (enabling team)

Если вспомнить про Team Foundation, IT4IT та самая enabling team.

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

В ОТП не стали выбирать путь создания пайплайнов за команды. Вы ведь помните, что DevOpsов в командах нет?:) Эксперты из IT4IT приходят в команду, которой требуется определенная помощь (например, с пайплайном). В этом случае члены команды разбираются в проблематике с девелопером и вместе пишут пайплайн.

Почему был выбран именно этот путь? Есть ведь распространенная альтернатива создание пайплайна вместо команды. Давайте посмотрим, как бы это выглядело на практике: эксперт из Enabling team делал бы пайплайн, отдавал его в эксплуатацию и уходил из команды.

Вроде бы, бинго! Продукт активно развивается, меняются конфигурация приложений и инфраструктура, окружение, появляются новые интеграции. Но все это требует доработки и внесения изменений в пайплайн. А экспертиза внутри команды, в случае написания пайплайна, не была бы проведена. И никто в команде не понимал бы, как провести доработку.

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

Облака и микросервисы

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

В ОТП выбрали подход использования облачной инфраструктуры, заключили договор с провайдером и начали осваивать public clouds. Важный нюанс: речь идет о банке, где очень беспокоятся о безопасности. В публичные облака договорились выносить только то, что не содержит чувствительных клиентских данных.

Сейчас в ОТП идет работа над внедрением Private cloud, которое позволит размещать любые сервисы и даст командам возможность еще более гибко управлять своей инфраструктурой. В дальнейшем public и private будут связаны. Командам не придется ждать, пока будет создана необходимая классическая инфраструктура. Это положительно отличает ОТП от других банков.

Все эти изменения произошли буквально за полгода.

На данный момент в ОТП уже есть:

• 8 трайбов, 60+ команд и продуктовая разработка;

Часть трайбов сфокусирована на определенных бизнес-направлениях, а еще есть три IT трайба, которые поддерживают CORE-платформы, общебанковские сервисы и сервисы для IT.

• Матричная структура и функционально/административная подчиненность;

• Чаптеры и гильдии по всем трайбам;

• Слой в 60+ API вокруг CORE-систем;

• Большая часть (90%) команд находятся на централизованном стеке CI/CD;

Изначально у всех были и GitLab, и Jenkins, и инстансы Nexus. Однако централизация важный аспект для банка. Она позволяет ускорить наращивание экспертизы, упрощает обмен опытом и знаниями.

Уроки, вынесенные во время трансформации

Lesson 1. Негативный эмоциональный фон

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

Настолько, что несколько человек решили уйти без какой-то конкретной причины, а просто из-за ощущения неопределенности. Казалось, что ситуация тяжелая, но обратившись к сухим фактам, в ОТП поняли, что даже в самый пиковый по уходам месяц среднегодовой показатель текучки персонала не превысил 13%, при рыночном бенчмарке в 10-15%. То есть происходящее ощущалось страшнее, чем было на самом деле.

Кроме того, оказалось, что всех уходящих объединяло одно желание: они хотели просто писать код. То есть you build it, you run it, DevOps, автоматизация и прочие штуки были им не интересны. Таким узко-специализированным профессионалам стало сложно продолжать получать удовольствие, когда вокруг наступили всеобщие эджайл и гонка за тайм ту маркетом. Сложившаяся ситуация была взаимовыгодной: уходящие, будучи крутыми профи в своей сфере, нашли себе команду по душе, а в ОТП продолжают развитие культуры, не тратя силы и время на перевоспитание тех, кому это не интересно.

Lesson 2: Внезапный COVID

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

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

Lesson 3: Измерения важная часть DevOps культуры

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

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

Поэтому было принято решение запустить ручной assessment и условно измерить, насколько в командах все хорошо с точки зрения:

• Процессов;

• Техники;

• Архитектуры.

Когда assessment был запущен, его показали топ-менеджменту, и все сказали: Вау! Круто! Давайте это запускать везде, где только сможем. И в этот момент было принято важное решение о том, что полученные оценки не должны стать KPI. Ведь assessment базируется на честности и открытости. И ОТП доверяют своим сотрудникам какая же DevOps культура без доверия?

В какой-то момент heatmap выглядел так (это только часть, просто чтобы дать некоторое общее видение):

Есть определенный трайб, в нем команда 1,2,3, а у них несколько приложений. Базируясь на их ответах, можно понять, что происходит, и построить heatmap вместе с Agile коучами и архитекторами. Здесь можно увидеть интересующие практики, подчеркнуть сильные стороны трайба и команды, наметить основные зоны роста.

В дальнейшем планируется, что, как минимум, техническая часть этого assessment будет автоматизирована.

Кроме того, принято решение о том, что в ОТП станут опираться на четыре основные метрики DORA, о которых много говорится в Accelerate. Например, есть идея, чтобы Lead time распадался в дальнейшем на все составляющие SDLC процесса, которые происходят условно от события git push до выкатки в продакшен. Таким образом, его можно будет измерить. А каждая из составляющих второго уровня метрик распадется, в свою очередь, на еще большее количество технических метрик (наличие и использование код-ревью, сколько времени согласовывается pull request и пр.).

И, конечно, этот assessment будущего по-прежнему не будет являться основой для KPI.

Lesson 4 Любая трансформация это в первую очередь люди

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

Важно управлять ожиданиями со старта трансформации. Сейчас даже на этапе интервью в компании уделяют большое внимание проверке вовлеченности: насколько человек в принципе готов к продуктовой разработке, как относится к T-shape или готов ли он надеть на себя шапочку QA, когда и если это потребуется?

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

Подытожим

Что в ОТП вынесли для себя:

• Запуск нескольких трансформаций значительно увеличивает риски неуспешности каждой из них.

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

• Важна плотнейшая работа с людьми, в том числе:

Информационные события и постоянный подогрев информационного поля;

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

Персональное общение и индивидуальный подход.

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

• Существенные единовременные затраты.

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

• Во время трансформации рекрутменту придется несладко.

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

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

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

С 1 апреля стоимость билетов на наши ближайшие конференции:TeamLead Conf 2021,DevOpsConf 2021иHighLoad++ Весна 2021возрастет.

Хотите получать полезные материалы по DevOps?Подписывайтесьна рассылку.

У бизнес-разработчиков за дедлайнами, сроками, клиентами и большими запусками может складываться впечатление, что инфраструктура выстраивает свой воздушный замок, который далек от того, что происходит в действительности. Захотев это изменить, Алексей Данилов из разработки перешел в команду инфраструктуры последние два года он развивает ее в Яндекс.Вертикали а это Яндекс.Работа, Яндекс.Недвижимость, auto.ru и Яндекс.Объявления.

Особенность Яндекс.Вертикалей ребята одновременно и бизнес-юнит Яндекса, и обычная IT-компания. Благодаря первому, у них есть возможность использовать яндексовую инфраструктуру, но, благодаря второму, разработчики смотрят на весь стек и используют то, что им удобно. Алексей сегодня поделится с нами, как это можно сделать более удобно и ближе к пользователям (в его случае к разработчикам). А также о том, почему на инфраструктуру сейчас надо смотреть как на продукт и какие вызовы это приносит команде, но что это дает в конечном итоге компании.

Infrastructure

Под инфраструктурой я подразумеваю всё, что окружает бизнесовый код и помогает ему от начала разработки фичи до момента ее доставки. Это и базы данных, и балансировка, и мониторинг, и CI с CD. Сюда же относятся особенности разработки/работы, библиотеки, тестирование, бизнес аналитика, бизнес-специфичные возможности и много чего еще. Это как завод, на котором вместо ручного труда автоматизированы все процессы, и результат мы получаем более быстрый и более качественный.:

При этом я рассматриваю инфраструктуру как единую платформу, а не набор разрозненных частей, которые я перечислил выше. И это уместно для компании любого размера. В облаках Amazon Web Services, Yandex Cloud автоматизация может строиться, например, на основе terraform. У вас может быть собственное железо или вы его где-то арендуете и на нем может быть развернут Kubernetes, Nomad, что-то еще. Команда тоже может быть любой от нескольких человек, которые в основном используют bash или terraform, и до сотен, со своими велосипедами.

И тогда возникает вопрос как добиться идеальной инфраструктуры Platform as a Service, который мы реализуем для наших пользователей, и вообще каковы критерии идеальности? Нам не нужно разрабатывать еще один Amazon или Kubernetes поэтому достаточно небольшой и простой системы, но у нас должна быть возможность ее расширения под наши use cases. Например, если у нас есть какие-то особенные АБ-тесты, особенные условия доставки (например, канареечный релиз ) и особенные правила безопасности это как раз то, что должна закрывать инфраструктура.

Ее основой, краеугольным камнем будут минимизация/ускорение разработки, упрощение поддержки и простота использования. Остальные требования понятность, доступность, стабильность и единообразность/распространение практик, а также скрытие низкоуровневых особенностей (чтобы никому не пришлось писать самому конфиг nginx или сложный Kubernetes манифест), техническая поддержка 24*7 и связанность компонентов конечно, тоже имеют место.

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

Infrastructure/Platform as a product (PaaP)

Сначала мы, конечно, смотрели в сторону сторонних приложений. Например, мы серьезно рассматривали Spinnaker от Netflix. Но он написан на Java, а у нас все пишут на Go, и мы не хотели добавлять еще один язык. Во-вторых, он не поддерживает Nomad и Yandex.Cloud. Следовательно, нам пришлось бы его прилично дорабатывать и интегрировать с нашими внутренними особенностями, что практически равно форку. Поэтому мы стали писать свое.

Изначально мы задумывали Shiva как абстракцию над деплоем (в нашем случае над Nomad) и как multicloud. Но сейчас она уже приросла различными системами и интегрируется со всем, что у нас внутри есть:

Основная ее часть представлена в GitHub в виде карты сервисов. Она изменяется посредством пул-реквестов, конфигурирует балансировку, контролирует деплой и различные пайплайны доставки, SOX, PCI DSS и т.д. То есть это одно описание для полноценной работы:

Архитектура Shiva в упрощенном виде выглядит так:

Сервис постоянно развивается и сейчас он уже частично похож на продуктовый: есть БД, вокруг которой построены различные микро-сервисы, есть небольшие legacy-компоненты (компонент Updater и Shiva смотрят в одну базу) и т.д. То есть с технической точки зрения он развивается как обычный бизнесовый сервис.

UI мы реализовали в Telegram, а впоследствии написали WEBовский. Telegram-бот это CLI over Telegram все команды задаются в формате CLI, но дополнены различными контекстными действиями, кнопками и т.д. Нам нравится этот подход, потому что он кросс-платформенный, его легко обновлять и к нему всегда есть доступ. Можно спокойно обновить или откатить свой сервис в случае проблем. А также очень удобный механизм нотификации, когда вы получаете уведомление о начале процесса деплоя прямо в тележку.

И хоть WEB и получился удобным, все равно часть пользователей остается в Telegram. Потому что UX меняется в профессию приходит очень много молодых разработчиков. Мы привыкли к WEB, мы привыкли использовать Telegram-боты и вообще общаться в чате. С другой стороны, мы хоть и думаем сделать CLI с такой же функциональностью, но понимаем, что запросов на это не было.

Экономика

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

Но у инфраструктуры нет доходов, тогда как на этой схеме есть и доходы, и расходы. Доход от инфраструктуры равен 0 это расход компании, а ROI будет отрицательным: сколько инвестиций не вкладывай, они не отбиваются:

Profit = Revenue - Cost = 0 - X

Есть, конечно, плюшки в виде, например, бесконечного LTV (LifeTime Value) то есть наши клиенты от нас никогда не уйдут. Но в целом эта метрика нам не подходила, и мы стали думать в сторону velocity (скорость разработки), потому что ее довольно легко преобразовать в деньги. Например, если мы ускорили разработку на час в неделю, то это нетрудно соотнести со средней зарплатой у 500 разработчиков и получить какой-то видимый профит. Вообще инфраструктура это именно velocity, то есть скорость доставки ценности пользователю. Но у нас это не глобальная метрика, потому что velocity зависит от очень многих факторов. : Если смотреть сверху, то можно выделить:

• code время написания самой логики ;

• infrastructure code время написания инфраструктурного кода (код логов, метрик, алертов и т.д.)

• environments время на настройку переменных окружения, секретов и т.д.;

• delivery время, затраченное на доставку.

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

В нашем случае мы написали GitHub-бота, который с очень большим спектром валидации проверял эту карту и мгновенно отвечал: либо всё хорошо, либо есть какие-то конфликты с другими картами и сервисами:

Следующим нашим пунктом разработки инфраструктуры как продукта стало внедрение user story.

User story

User story это фундамент любой продуктовой разработки и используется он в любых гибких методологиях идущих от Agile. Это не детальное описание задач давайте прикрутим здесь кнопку, которая будет делать вот это. User story это намерение пользователя: какую проблему пользователь решал, как он пытался её решать, почему он её решал, почему она возникла, и, наконец, как мы можем её решить. Разумеется, из user story выводится очень много различных решений. Но сам User story не является им это основа для решения и инструмент для выявления исходной проблемы.

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

Приведу для примера две наши внутренние истории.

Пример 1. Залипает обработчик Кафки. Чинится только рестартом сервиса. Фикс в пути. Хочется иметь способ быстро перезапустить контейнеры.

Проблема была понятной и мы предложили сделать команду restart -l prod my_service, в которой указывается слой сервис, чтобы сервис рестартился через телеграм бота.

Пример 2. При обновлении конфигурации хочется перезапустить сервис без указания версии.

Решением стало: /run -l prod -v 1.0.7 my_service -> /run -l prod my_service.

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

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

То есть разделяя user story, мы можем их по фидбэку развивать дальше. Но даже просто использование user story дает огромный профит, так как мы начинаем слышать пользователя о его проблеме. Но если общаться с пользователями и вместе находить решение не каждая user story будет реализована, и не каждая так, как мы придумали.

Customer development (сustdev)

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

1. Выявляем потенциальную проблему (строим гипотезу), формируем идею или решение, но не внедряем ее, а идем к пользователям, чтобы поговорить с ними об их потребностях/болях/проблемах.

2. Встречаемся с ними, например, на кофе-поинте или на рабочем месте. Можно пообщаться и в Зуме. И в обсуждении можно обнаружить, что проблема пользователям не важна она не так много времени занимает и не так сильно его напрягает, но зато у него есть более важные проблемы.

3. Прорабатывая решение вместе, мы получаем либо изначальное успешное решение (если определили проблему верно) или более успешное (поняв из общения, что волнует пользователей) то есть в выигрыше все.

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

Эта история решилась довольно просто. Мы добавили время деплоя в аннотации на Grafana, и теперь видя какую-то аномалию, можно понять, не было ли деплоя, в том числе деплоя зависимых сервисов. Эта история, кстати, ускорила у нас создание WEB UI.

А потом мы пообщались с тимлидами и выяснили, что они это видят совсем по-другому:

Developer: Я вижу по графикам проблемы нужно проверить, не связано ли это с выкаткой новой версии (см. график выше).

Team leads: Нужна возможность посмотреть кто, что, когда и зачем катил в прод:

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

Портреты пользователей и сервисов

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

• Разработчики: бэкенд, фронтенд и инфраструктура;

• Team leads;

• Тестировщики/Автотестировщики;

• Аналитики;

• Менеджеры, продукты, руководители.

По сути частичное отражение рабочих позиций :)

А портреты сервисов можно классифицировать по типу, языку или размеру. Первые бывают внутренними (realtime api, back api, async, cron, gateway, и т.д.), DB, внешними, saas и т.д. И они богатая точка роста, потому что это место отказа каких-то инфраструктурных частей. Это и наша точка роста, которую мы рассматриваем в будущем для себя.

Языки разработки мы рассматриваем нечасто, но иногда приходится смотреть: почему эта история возникает, у кого она возникает, потому что, например, у java и node.js бывают небольшие различия в работе, и это приходится учитывать.

По размеру портреты сервисов могут быть: function, microservice, service, monolith, distributed monolith и т.д. И если мы, например, понимаем, что проблематика идет из распределенного монолита, то отказываем в этой истории, потому что у нас хорошей практикой считаются мироксервисы и нашим PaaS мы популяризируем и упрощаем жизнь именно с ними..

Вот для примера портрет сервиса БД. С помощью этой карты ставятся бэкапы, происходит доступ к БД на чтение/запись и т.д. Плюс, сам сервис в свои зависимости прочерчивает эту карту, и мы знаем, что это за карта и от чего она зависит то есть, мы знаем, что сервис А зависит от базы данных В:

Feature request

Но одно дело найти проблему. Совершенно другое когда приносят уже готовое решение. Это самая богатая тема, которую можно использовать себе на благо.

Конечно, у нас есть проблемы:

• Технически грамотный пользователь может принести уже готовое решение, например: Сделайте такой API, в БД все сохраните, и на этом хватит.

• Личное знакомство потому что иногда мы отказываем в feature request или говорим, что будем делать по-другому, и возникает небольшой конфликт.

Но есть и решения:

• Превращать в user story находить проблематику: узнавать, с какой проблемой столкнулся пользователь и как пытался решать;

• Смотреть на доработку в контексте портретов кто к нам пришел, что за сервис, о чем идет речь;

• Спорную доработку или ту, в которой мы не уверены, проверять через castdev, потому что все-таки feature request приносит один пользователь и непонятно, насколько это ценный функционал для всех;

• Механизм голосований/рейтинга это самый мощный инструмент. Он не нов, используется во всех хороших продуктовых разработках, например, в терминале Тинькофф-Инвестиции. У них открытые feature request, где люди открыто голосуют и в итоге в работу идут те, что в топе:

Внутри это также можно легко реализовать, потому что мы работаем в рамках одного issue-трекера. Например, здесь фильтры по нашим feature request:

Из интересного: мы недавно этот вид сделали через наш WEB не таким формальным и увидели, что люди с большей охотой голосуют за идеи то есть это тоже важно:

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

Roadmap

Хочу отдельно сказать про Roadmap. Это кажется довольно банальной темой, но пообщавшись с разными компаниями, я обнаружил, что у команды инфраструктуры часто не бывает долгосрочного видения. Есть понимание, что они делают через неделю или месяц, но нет понимания, какой должна быть в итоге инфраструктура. И обычно это инфраструктура посредством одной кнопки, когда все описано в GitHub-репозитории и сделана она, например, на CI сборках. Куда стремиться непонятно.

Ценность даже не в самом плане, а в процессе планирования. Когда мы планируем, мы думаем, что хотим дать пользователям, поэтому roadmap удобно сделать открытым можно сразу получить фидбэк. Мы можем расставить истории по приоритетам, фидбэк может сказать нам, что большинству намного важнее то, что мы отложили. Так что публичные и регулярно обновляемые планы помогут вам скорректировать roadmap и строить долгосрочный бэклог на его основе.

Кстати, как получать обратную связь?

• Тикеты и подписки на них. В нашем случае это самый рабочий инструмент, потому что мы работаем в одной компании, и в одном трекере.

• Большие посты анонсы. Несколько раз в квартал мы делаем большие анонсы, где рассказываем про всю большую функциональность и опять же получаем фидбэк. Иногда мы получаем негативные отзывы, например: Зачем вы это делаете, если можно взять вот это и то. Тогда мы либо объясняем, либо понимаем, что, может и правда можно реализовать более просто.

• У нас есть групповой чатик в Telegram/Slack/Microsoft Teams. В основном мы там собираем обратную связь, хотя он работает как инструмент технической поддержки, а также в нем выкатываем нововведения с небольшими инкрементальными релизами.

• Открытые встречи для вопросов/ответов. Мы пока что провели её только один раз, но результат был неплохой.

• Еще можно встречаться на демо продуктовой разработки и там отвечать на вопросы. Но мы не проводим демо сейчас для нас это большая потеря времени.

• Еще можно использовать индекс потребительской лояльности NPS (Net Promoter Score). Это простые анкеты: насколько вы удовлетворены нашим сервисом, насколько вам удобно базовые вопросы для того, чтобы собрать общую статистику лояльности пользователей. Мы не используем NPS, потому что из чата получаем и критику, и позитив, а остальных записываем как нейтральных пользователей.

MVP

После планирования хочу напомнить про инструмент MVP (Minimum Viable Product). Это известный подход, но в инфраструктуре есть нюансы. Мы, как любой бизнесовый продукт, выкатываем частично недоделанный продукт, где-то не самый удобный, но минимально рабочий. Потому что мы не можем делать 2-3 месяца какую-то историю, выкатить её, получить средний фидбэк и потом еще месяц переделывать:

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

Например, когда мы резолвили свой первый WEB, его функциональность была далека от функциональности Telegram, да и выглядел он неказисто, если честно. Но впоследствии он развивался, мы получали фидбэк, и в результате даже пошли по другому пути, потому что UXe (пользовательский опыт) отличается от того, что было в Telegram, и от того, что есть в WEB.

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

Overkill

Важно понимать, когда продуктовый подход становится слишком сложным. Бизнесовые команды становятся настолько большими, что состоят из множества людей с разной направленностью и спецификой. Есть product owner, цель и задачи которого выстраивать roadmap и определять, какие из историй делаются. Есть product менеджер, UX-специалисты, разработчики, тестировщики и т.д. Когда большие истории разбиваются только по user story и пытаются делать с добавлением какой-то пользовательской ценности. Всё это очень круто, но сейчас для нашей команды это overkill. Как в принципе, и A/B-тестирование.

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

• Стараться понять: Зачем? То есть не Разработчик хочет 500 Тб БД, а: Разработчику нужно сохранять информацию о машинках (которую мы никогда не сохраняли) тогда мы сможем работать вместе над одной проблемой пользователя

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

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

• Обязательно нужен механизм голосования за идеи для того, чтобы упростить scoring задач.

• Собирать roadmap и сделать его открытым.

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

• Нужно много автотестов , так как я все еще не представляю вакансии тестировщика в команде инфраструктуры, как и дизайнера по крайней мере в 2021 году.

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

Итог

В заключении рекомендую книгу Психбольница в руках пациентов Алана Купера я ее прочитал очень давно и с огромным удовольствием, она меня вдохновила. Сейчас настало время, когда ее стоит рекомендовать не только product owner, продуктовым разработчикам, дизайнерам, но и команде инфраструктуры. Там очень много полезных примеров, в которых можно найти себя.

Подытоживая:

• Разговаривайте со своими пользователями, находите проблематику надо искать проблемы, а не решения.

• Относитесь к внутренней инфраструктуре как к единой платформе, как к единому PaaS.

• Разрабатывайте PaaS как полноценный внутренний продукт.

• Используйте проверенные простые продуктовые подходы, но только те, которые окажутся простыми. Если тот или иной подход (тот же сustdev или портреты пользователей) кажется сложным, возможно, сейчас их не стоит использовать.

• Повышайте ценность PaaS (скорость/расходы разработки/поддержки).

• Создавайте современные интерфейсы.

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

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

Профессиональная конференция DevOpsConf 2021 пройдёт 31 мая и 1 июня этого года в Москве, в отеле Radisson Slavyanskaya. Расписание уже сформировано. На сайте вы можете познакомиться с программой и спикерами.

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

До встречи в оффлайне!

Мы хотим расти не только внутри в компании, но чтобы за её пределами это имело какой-то смысл. Наши руководители хотят простых инструментов и переговоров, чтобы как-то выдерживать диалоги на тему Хочу роста! или Хочу еще +X денег! А компания в то же самое время хочет развития компетенций и большей автономии сотрудников.

В Wargaming Platform смогли учесть интересы всех трех сторон им помогли карьерные уровни и в развитии людей, и в формирования к ним ожиданий. Wargaming Platform это инженерная организация, которая решает общие проблемы для разных игр (тех же Танков, Кораблей, Самолетов): как залогиниться, как заплатить, как написать тикет в саппорт, как сделать что-то еще общее для всех игр. Илья Росляков занимается в ней тем, что разруливает ситуации между руководителями и сотрудниками на тему роста и развития, и в том числе руководит несколькими командами разработки, DevOps практикой. Сегодня он расскажет, как в компании внедряли его инициативу о карьерных уровнях и что получилось в результате.

Почему мы вообще подумали, что нам карьерные уровни помогут?

В целом, у нас уже был развитый институт People Management: люди делали perf-review, one-on-one, встречались, разговаривали о развитии то есть почва для карьерных уровней уже была готова. Мотивация роста у каждого, конечно, была своя: кто-то хотел денег, кто-то признания, а кто-то растил собственную автономию. Путь у всех был разный, но главное люди уже хотели расти.

В то же самое время наши эйчары выяснили, что в компании более 75% профессионалов, т.е. каждый несомненный эксперт в своем деле, и в то же время среди них:

• Первые 40% были не автономны и нуждались в развитии то есть им постоянно была нужна помощь руководителя и/или коллег, чтобы делать их обычную работу.

• А другие 40% были автономны в собственной работе, но не отвечали за развитие других. Они сами были автономны, но вокруг трава не расти!

То есть с точки зрения компании только 20% сотрудников - гуд. Тогда мы изучили опыт топовых IT-компаний: ко такой тимлид, техлид и что происходит в Big 4 (Google,Amazon, Apple,Facebook) чтобы людей правильно направлять не только в нашем взаимодействии, но и в целом по жизни. По ходу дела мы также поняли, что у нас есть много людей, которые делают похожую работу то есть, генерализация тоже будет иметь смысл.

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

Зачем это руководителям?

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

Зачем это компании?

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

Зачем это сотрудникам?

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

Остальные опции связь с внешним миром, открытость в переговорах тоже здесь доступны. И это еще и возможность почелленджить своего руководителя. Ты приходишь и говоришь: Хм, а вот в Google не так А FaceBook иначе делает Понятно, что это не всегда конструктивная беседа, но вы начали говорить хотя бы это уже круто.

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

Решение

Карьерные уровни можно было бы представить как-то так:

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

ЗП = компания + регион + (роль + карьерный уровень + ЗП-вилка) = грейд

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

• Смена роли;

• Смена карьерного уровня;

• Смена внутри уровня: изменение обязанностей, перф.

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

На внешние мы не можем повлиять:

• Рынок он такой, какой есть: одни люди становятся дороже, другие дешевле.

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

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

На что-то мы влиять можем:

• Очевидно, что на роли, карьерные уровни, на свой перф. Перф это raw performance человек просто больше работы делает. Или по другому: average как человек в среднем работает.

• На нашу стабильность вообще на нашу жизненную синусоиду, среднеквадратическое отклонение, насколько нас колбасит в работе.

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

Плоский граф требований

Мы начали с инженеров, потому что в них разбираемся. Мы написали много смартованных требований, типа: Коммуникация занимает не более, чем 20% времени инженера. И дальше для каждого уровня добавлялись новые:

Но в какой-то момент мы поняли, что зашли куда-то не туда. Что же пошло не так?

• Требования многократно наследовались. Кто писал код на каком-нибудь ООП, знает чтобы развернуть наследование очень далеко назад, нужен просто взрыв мозга, чтобы разобраться: Так, а кто сеньор? Вот этот? А он еще от миддла что-то наследует. жесть, в общем.

• Навыки были разрознены, и строчка каждый раз была новой. Они визуально очень сильно различались, и при этом записаны были тоже сильно по-разному: где-то про языки, где-то про коммуникации. Это было очень сложно читать.

• Критерии были бинарными (смартовыми). Смарт это хорошо, но не в случае с людьми. Представляете, вдруг выясняется, что у кого-то какой-то процесс занимает 19% времени но зачем и как он это считал?! Но даже если посчитал вот он приходит к руководителю: У меня 19 А надо 21 и начинается bullshit.

Двумерная матрица

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

У нас получилось 7 уровней по горизонтали от 1 до 7. Это было лучше, но все же кое-что снова было не так:

• Семь уровней компетенций были неразличимы между собой. Например, уровень знаний на четверочку по семибалльной шкале что это значит? У нас никто так и не смог до такой степени глубоко прочувствовать все эти сферы, чтобы делить от 1 до 7.

• Рост ожиданий остался дискретным чтобы понять правую верхнюю ячейку, нужно было остальные тоже прочитать, потому что они так или иначе связаны.

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

Трехмерная матрица

Всего в этой табличке у нас было 42 строчки. Мы добавили веса, чтобы убрать дискретность всё стало гибко, подробно, но... стало просто ничего не понятно. Люди за пределами рабочей группы вообще перестали понимать, о чем мы разговариваем.

Тогда мы сильно откатились и очень упростились, чтобы поменять матрицу.

Двумерная матрица и линейка

Мы выделили 6 ключевых компетенций:

1. Знания,

2. Sharing,

3. Инновации,

4. Сложность задач,

5. Цель/Просто задачи,

6. Автономный менеджмент.

И описали для каждой те минимальные требования, которые удовлетворят карьерный уровень. Уровни же определили просто: 0 нет компетенции, 2 сформированная компетенция и т.д. Но снова не пошло, так как выяснилось, что описания уровней компетенций бессодержательны например, что такое conscious, я и сам с ходу забыл.

Тогда мы изучили крупные компании типа Google, Electronic Arts и т.д. и оттуда позаимствовали некоторые названия компетенций. Но все еще не хватало точности в определении, какого же уровня каждый сотрудник.

Area of Effect (AoE)

И тут мы подумали мы же игровая компания в конце концов! И ввели понятие Area of Effect (AoE), который измеряет постоянное и позитивное бизнес-влияние компетенции в текущей компании. Звучит длинно, а на мы соединили 6 компетенций и AoE от 1 до 5:

1 Сам человек, например, у него sharing прокачан только в себя;

2 Это что-то на команду. Сами решайте, что для вас команда например, это постоянная группа людей.

3 Несколько команд или несколько неопределенных групп людей;

4 Бизнес-unit. Например, мы считаем у себя в Wargaming, что это Platform. Но у кого-то это будет целая компания. Если кратко, то это достаточно крупная и независимая бизнес-организация со своими P&L и пр.

5 Очевидно, мир.

Как проверить, например, что такое Innovation 4? Это когда я могу выти и на весь бизнес-unit сказать: Иван Иванович инноватор масштаба нашей компании!, и если на галерке никто не заржал, то это, глядишь, и правда. Если заржал, то: Ну, ладно, инноватор вон тех Что?! Я понял. Двоечка.

Калибровка

Но когда мы начали маппить наших инженеров между разными компаниями, там такая дичь началась: тут все P4, а там все P5! Поэтому мы ввели калибровку для P4 и выше это помогло, хотя и не на уровне мира. Потому что никто не калибрует уровень P2 среди компаний карьерные уровни в них разные и с этим ничего не сделать. Но максимальный карьерный уровень может быть одинаковый, потому что он глобальный и инженеры из The Big Four задали нам верхний предел.

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

А польза-то какая?

Самое первое, что мы увидели с 2019 года люди стали меньше уходить из компании по причине недовольства собственным ростом.

В остальном мы все еще в процессе наблюдения и настройки. Мы все еще смотрим, насколько руководители работают с карьерными уровнями, насколько сотрудники понимают эти уровни и насколько они им помогли расти профессионально (не карьерно). Поэтому мы еще будем докручивать и досчитывать два пункта:

• Руководителям понятен подход и они им пользуются;

• Сотрудники знают, как могут расти довольные своим профессиональным ростом через год.

А пока я покажу вам на примерах, как работают карьерные уровни.

Примеры для инженерных компетенций

Knowledge

Что ожидается от инженера? Самое простое это knowledge. Это не какой-то knowledge в вакууме типа: Умею писать на Python, но ничего не знаю про базенки и vim никогда не открывал. Это знание какой-то специфики, которое в принципе трудоустраиваемое.

Ноль это отсутствие знания. А для единички, например, мы решили, что это около двух лет коммерческого опыта. Двойка это эксперт уровня команды в какой-то технологии, например, главный питонист в команде на 7 человек, главный эксперт в БД, в Кубе, в чем-то еще. А дальше с тройки по пятерку просто scale, например, тройка главный в нескольких командах, четверку по knowledge заработал бы главный эксперт в Python в бизнес-unit, а пятерку core-контрибьютор PostgreSQL.

Sharing

Sharing самая простая штука это насколько мы шерим.

Единичка это человек, который отвечает на вопросы. К нему подошли: Поможешь? Да. Он готов разговаривать. Если кто-то накрывается полотенцем и не отвечает, то это ноль. Начиная с двойки и в пятерку опять простой scale. Двойка шерит знания проактивно, и замечу, постоянно, с пользой для компании. То есть это не просто человек, который ходит и кричит: Перепишем все на OCaml! (Зачем, почему, мы вообще на 1С тут) должна быть польза, и она должны быть хоть как-то измерима, хотя бы каким-то экспертным мнением и в текущей компании, а не где-то в воображаемом мире. Это также может быть человек, который онбордит новичков в команде, причем по собственной инициативе. Пример пятерки это постоянный спикер на внешних интернациональных конференциях.

Innovation

Инновации это когда вы в компании предлагаете что-то полезное (польза определяется постфактум), и делаете это периодически.

Нолик, получается, ничего не улучшает. Единичка улучшает внутри себя, например, свои собственные методы работы. Двоечка улучшает внутри команды. Предложили что-то в команде, оно зашло о, несем в другие команды. Можно затащить в компанию то, что не является уникальным какой-то процесс, например, people performance process в компанию это будет уже четверочка, потому что с точки зрения компании это уникальная инновация. Пятерка это тот, кто изобрел React.js и вытащил его в мир.

Complexity

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

Отработать пятерку это создать компанию по сути дела, у меня это написано как Реализовать Platform. Четверка это тот, кто понял, как реализовать части этой компании, например, из чего состоит Platform: биллинг мы должны считать, большие фичи пилить, метод взаимодействия определить. Тот же TrackingID наш внутренний туллинг, считающий, как разные игры утилизируют наше железо это четверка отработал и внедрил его. И дальше по аналогии та же двоечка реализует какой-то спайк в Agile, например, маленький research на неделю, на две, на три.

Goals/tasks

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

Autonomy/management

Для роста инженерам менеджмент-скиллы тоже нужны очень сложно расти профессионально, если никому ничего не рассказывать и не доводить до конца. Если вы ходили на Менеджмент 3.0 это единичка это тот человек, который взял задачку, декомпозировал ее, проинформировал про решение, пошел делать и в принципе сделал. То есть это достаточно автономный человек, но его надо проверять иногда он может уйти в какой-то поток.

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

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

Оценка карьерного уровня

Для каждого уровня мы сформировали краткие определения:

• P7 это неопытный специалист;

• P6 это вполне уже самостоятельный человек для типичных задач;

• P5 это полностью автономный эксперт, инженер. Он все уже может сам сделать и кого-то еще менторит в команде;

Начиная с четверки начинаются люди, которые развивают других людей:

• P4 это тот, кто развивает других P5 по сути дела, то есть тех самых автономных профессионалов;

• P3 развивает P4 и т.д.

Плюс тут еще важен scale. На уровне P2 мы ожидаем, что человек развивает нам примерно 100 P5. А это означает, что в компании на 10 человек быть P2 вообще нельзя но можно, если вы, например, развиваете локальное community питонистов, где 100 сеньоров. P1 это бог.

Теперь расскажу, как меняются ожидания в зависимости от уровня.

Минимальные требования

Плюс для каждого уровня мы определили минимальные требования:

Как видно, от P7 мы ждем только, что он какое-то complexity преодолевает и с какими-то задачками работает. Например, это студент, трудоустраиваемый на какую-то позицию в нашу компанию. Мы ожидаем, что он может погуглить и хоть что-то довести до конца. Он ничего пока не знает, поэтому и на вопросы не может ответить.

Если Р7 начинает учиться, то к следующему уровню (P6) у него уже должны подняться знания, он должен стать более автономным и начать отвечать на вопросы:

К уровню P5 наш студент уже вырос во всем и начал инновировать (прекрасное русское слово!). P4, как и P3, тоже растёт во всем параметрам:

А вот дальше интересно. P2 это, наверное, уже техдиректор, 100+ человек в компании. Это первый человек, который вышел на мир. Фактически мы ожидаем от него, что он начинает шарить инфу прямо на пятерочку в пределах всего мира. Эт тот человек, который компанию представляет уже на мировой арене и инновирует в масштабах всей компании. И P1, наконец, канонизированный техдиректор, бог он всё.

Что с этим делать на практике? Давайте посмотрим на примерах.

Пример оценок

• Про Лео можно сказать, что это в целом ровный чувак, который нормально шарит не в смысле в чем-то разбирается, а шарит информацию.

• Раф в чем-то прикольно разбирается, а в чем-то лучше своих коллег, и он массово учит людей. Это просто mass DDoS teacher людей!

• Майк очень автономный человек, который координирует какие-то задачки, он очень самостоятельный.

• А Дон не просто самостоятельный, он еще и сложные задачки решает самостоятельно вообще молодец!

• Кейси же человек-идея. У него всегда есть идеи, причем полезные, и это важно. Это человек постоянная полезная идея в своей компании.

Дальше появляется странная математика.

Благодаря минимальным требованиям, мы можем недостаток одного балла в какой-то компетенции компенсировать баллами сверх минимума из других. Например, если у вас не хватает sharing на единичку, то это можно компенсировать +1 knowledge и +1 complexity. Потому что и knowledge, и complexity у человека имеются сверх наших ожиданий на этом уровне.

Пример плана развития

Благодаря плану развития, вы можете сказать человеку, как ему развиваться: Ммм, Элис, тебе нужно начать рассказывать о том, чем ты занимаешься. Это типовой портрет Элис, которая недавно пришла в компанию. Она в принципе во всем шарит, но пока никто не знает, кто такая Элис. Как правило, для нее план развития просто живи, выживай, рассказывай о своей жизни.

Кто такой Боб? Боб что-то классно знает, но, блин, никто не знает Боба! Он никому не рассказывает, чем он занимается. Он роняет задачки, которые в него вбрасывают. Вообще непонятно, кстати, как мы поняли, что он шарит? Кто-то сделал best guess, видимо. План развития Боба: Чувак, вылезай из угла.

У Пита вообще сложная жизнь. Он в чем-то лучше разбирается, у него неплохие идеи, но задачи ему лучше вообще не давать, их только вместе с PM стоит ему отправлять. У него много проблем.

А дальше магия. Мы собрали команду из этих ребят, и вдруг выяснилось, что у команды все нормально. Они друг друга сбалансировали и нигде нет провалов. Даже knowledge по команде в целом лучше, чем у соседей. Так этим туллингом можно балансировать между собой разные команды:

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

Вспомогательные механики

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

Карьерная лестница

Что такое карьерная лестница? Это что-то внутри software engineering либо внутри саппорта.

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

Карьерная карта

Я здесь в качестве примера привел P4 инженеров. А кто такой P4 Python разраб? Это же профессионал бэк-разработка и вообще software-инженерия. Но в целом это можно применить не только к инженерам.

Краевые случаи

Я описал наш путь в общем, но есть и краевые случаи, давайте их тоже рассмотрим.

A M-manager vs. a P-professional или лид внезапно

• Ключевая ценность: родитель или воспитатель в садике.

• Направление роста по соглашению с руководителем.

P (professional стрим) и M (manager) у нас отдельные карьерные пути, и это отдельный рост. Типовой запрос от внезапного лида обычно бывает: О, я кто P или M? То есть человек ждет, что я ему по методологии отвечу, но правильный ответ ты сам реши, кто ты.

Тут важен тот самый вопрос кем вы видите себя через 5 лет. Если вы собираетесь расти как профессионал, смотрите в P и растите там. Собираетесь расти как менеджер растите как M. Это зависит только от вас и вашей договорённости с руководителем.

Смена карьеры

• Роль определяется ключевой ценностью сотрудника.

Бывают кейсы, когда, например, QA-инженер P5 переходит в software engineering и у него падает карьерный уровень, он становится P7 либо P6. Это нормальная ситуация, и здесь нужно смотреть, какая у него ключевая ценность. Если он все еще трудоустроен, потому что в принципе в прошлом был хорошим QA, то возможно, какое-то время его стоит оценивать как QA. Если его взяли на software инженера и неважно, какой он QA ставьте ему P7 и растите как software инженера. То есть важно, вообще почему он у вас работает до сих пор.

Оценка новичков

• Делается на основе интервью и обсуждения ожиданий с руководителем.

Кто такие новички? Это люди с рынка, которых вы собеседуете. Тут важно с ними просто договариваться. Вы же не скажете им: Я беру тебя на P4 или на P5. Они такого не понимают. Но вы должны с ними договариваться о каких-то ожиданиях через какой-то срок. Это практически проект онбординга человека. Вы ожидаете от P4 вот это, и с этим человеком на входе договариваетесь: этого я ожидаю через полгода. Если через полгода не случилось, вы даунгрейдите человека это либо ошибка найма, либо самого человека. Но все равно нужно какой-то кредит доверия выдавать людям и договариваться.

Уровни в других компаниях

Прошлый уровень кандидата влияет только на его ожидания и зависит от:

• места компании на рынке,

• методологии которую использует компания,

• специфики технологий в компании.

Уровни в других компаниях другие. Есть компании, где ключевая сфера технологии (Google), а у кого-то e-commerce, и т.п. Очевидно, что нельзя, поменяв компанию, перейти на тот же уровень, потому что требования просто разные. Мы формулировки наших требований отправляем внешним рекрутерам в другие компании и спрашиваем: Эти люди у вас кто, судя по этим текстовым требованиям? Так мы делаем исследование рынка в текстовой форме.

То есть если к вам приходит человек с уровнем P2, то это влияет только на его ожидания и амбиции. Но вам толку от этого нет.

Понижения при внедрении карьерных уровней

• Это дар богов, освещающий путь.

Если вы будете внедрять карьерные уровни, и у всех станет минус 1 уровень, даунгрейд это прекрасно, это дар богов. Вы были P4-лидом, а теперь говорите: Я сеньор, и у меня P6 и это значит, что у вас будет четко обговоренный с руководителем план роста. У вас есть легко просматриваемые зоны роста, и это клево. Мы же не понижаем зарплату, мы этот инструмент используем именно для роста.

Недостижимые уровни или как попасть в Р1

• Вся жизнь между P6 и P5 это норма. Выше стресс и переработки.

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

Уровни и свобода личности

• Расти можно кем угодно. Но кто-то может быть не нужен компании.

Это очень противоречивый раздел, по формулировке ничего не понятно. Но это про открытость.

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

Влияние на интервью

• Уровни помогут понять рынок и спланировать бюджет;

• Уровни могут быть рекламой компании.

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

Локальное внедрение

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

• Знать уровни во внешнем мире,

• Понимать, что важно компаниям в целом,

• Создать инструменты переговоров и оценки,

• Изучить ошибки в эволюции.

Для начала это можно сделать не на всю компанию, а на три команды, например. Или внедрить несколько частей поначалу, а затем добавить остальные. Будьте Ниндзей, который всех затащит!

Подготовка к конференции TeamLead Conf 2021 вышла на финишную прямую до конференции остался всего месяц. Билеты раскупаются, мест становится все меньше. Поторопитесь с решением, чтобы попасть в офлайн-формат. На сайте конференции вы можете познакомиться с программой и спикерами.

А купив билет, вы можете получить в подарок мастер-класс Максима Дорофеева Как все успевать? На МК количество мест тоже ограничено мы должны соблюдать противоэпидемиологические меры и создавать дистанцию в залах. Поэтому гарантия участие в мастер-классе только предварительная запись.

До встречи на конференции TeamLead Conf 2021!

Поддерживать высокое техническое качество кода прямая обязанность техлида. Но чтобы этого добиться, зачастую приходится доказывать начальству и заказчикам необходимость вкладывать в улучшение кода силы и время. Как сделать это, не стаптывая в бесконечных согласованиях железные башмаки и не стирая язык до мозолей? Об этом в своем докладе на конференции TechLead Conf 2020 Online рассказал консультант Better Life Company Алексей Дерюшкин.

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

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

Проблемы Алексея выглядели так:

• Бизнесу совершенно неинтересно, что находится под капотом и как сделать код лучше;

• Бизнес не разбирается в системе и не хочет это делать;

• Сам техлид не умеет вести переговоры;

Представьте ситуацию: техлид приходит к бизнесу с классной идеей (глупо же ходить с плохими идеями!) он придумал ее и знает, что она поможет. Иногда уже знает, что не реализовать ее не получится. Начинает разговор, но беседа не складывается.

Почему?! Потому что техлид говорил о каких-то технических вещах, а коллегам из бизнес-подразделений не интересно, как это работает. У них другие цели и задачи: как повысить конверсию, как привлечь больше людей, как сделать классный продукт. И технические детали им не интересны.

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

У вас были ситуации, когда не получилось договориться с бизнесом? Если ответ да, контент ниже будет вам полезен.

Чем продажа идеи отличается от программирования?

Спойлер: ничем!

Есть три ключевые вещи, которые обязательно нужно сделать для того, чтобы успешно продать какую-то идею:

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

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

3. Использовать эмоции. С ними тоже нужно уметь работать. Но чтобы сделать это правильно, лучше пойти на какой-нибудь тренинг по эмоциональному интеллекту.

Пример неудачной продажи

Техлид приходит к владельцу продукта:

• Привет! Я хочу добавить в этот спринт задачу по рефакторингу.

• Привет! Нет, в этот спринт мы должны выпустить новую фичу, мы уже обещали.

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

• Ну, делайте сразу нормально, кто ж мешает?

Это результат неподготовленного диалога.

Давайте разберем ошибки типичного диалога техлида с бизнесом:

• Птичий язык: владельцу продукта непонятно, о чем мы говорим;

• Готовые решения. Человек, которому мы продаем идею, не участвовал в ее разработке. Он не знает, почему эта идея ему нужна и как она связана с тем, чего он хочет добиться;

• Потребность убедить в своей правоте, а не помочь решить проблему бизнеса.

Итог закономерен: бизнес чувствует себя дураком, искренне не понимая, зачем нужно делать техдолг, когда можно сделать фичу.

Система продаж Джордана Белфорта

Есть замечательная цитата:

В фильме Волк с Уолл-стрит с Леонардо ДиКаприо прототипом главного персонажа является Джордан Белфорт один из самых известных продавцов и автор системы продаж.

На чем основывается его система? Джордан утверждает, что у вас купят идею (а на самом деле купят что угодно: телефон, автомобиль и т.д.), если есть 100% уверенность:

• В идее (продукте, предложении);

• В вас, как эксперте;

• В людях, которых вы представляете.

Рассмотрим бытовой пример: вам продают автомобиль.

• Идея 71%

Вы не совсем уверены, что автомобиль нужен вам как продукт. Но все же вам нужно ездить из пункта А в пункт В (на дачу, возить ребенка в школу).

• Эксперт 83%

Вы почти уверены в продавце. То есть человек, который показывает вам автомобиль в салоне, вызывает у вас доверие.

• Команда 78%

Вы также достаточно уверены в том, кого представляет продавец. Это может быть известная компания по продаже автомобилей или определенная марка. Например, вы уверены в том, что ес ли купите Mercedes, он не развалится в первый день, и не уверены в том же самом с АвтоВАЗом.

Если во всех трех пунктах ваша уверенность 100% или близко, то скорее всего, автомобиль вы купите.

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

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

• Идея 0%

• Эксперт 100%

• Команда 100%

Автомобиль вам не нужен, в принципе. В автосалон вы зашли, чтобы согреться или спрятаться от дождя.

Если вы уверены, что автомобиль вам нужен, но при этом вы не доверяете продавцу вам кажется, что он хочет вас надуть или впарить 100500 опций, то конкретно у этого человека вы не купите:

• Идея 100%

• Эксперт 0%

• Команда 100%

В случае, когда вы не хотите связываться с АвтоВАЗом, и LADA Granta не ваша мечта, будет так:

• Идея 100%

• Эксперт 100%

• Команда 0%

То есть если даже один параметр будет не 100%, а 30-40% и ниже, вы не убедите человека купить автомобиль. А на месте техлида не продадите идею сделать тесты, что-то автоматизировать или провести рефакторинг.

Важный момент по поводу 100 баллов из 100. Вы можете только предполагать, каковы цифры на самом деле. Странно было бы на переговорах говорить человеку: А ну, скажи мне: от 0 до 100, насколько ты во мне уверен?. Это просто метафора, а не цифры, которые можно использовать в разговоре.

Как добиться уверенности на 100\100\100?

Идти по алгоритму.

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

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

Алгоритм продажи чего угодно, в том числе идей

Первые четыре секунды

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

Будьте доброжелательны и энергичны, но не слишком: не как персонаж из Маппет-шоу. Чуть-чуть энергичней, чем собеседник уже очень хороший уровень.

Кратко изложите, зачем пришли (позвонили, назначили встречу). Человек, скорее всего, чем-то занят, это элементарная вежливость.

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

Раппорт

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

Отсутствие раппорта очень хорошо описывает картинка:

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

Сбор информации

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

Давайте посмотрим на три пункта:

• Боли ярко окрашенные негативные эмоции;

• Выгоды позитив;

• Цели и задачи более нейтральные вещи.

Лучше идти сначала от боли, если она есть. А если нет, то от выгоды. Если нет ни того, ни другого, то просто апеллировать к задачам, которые человек перед собой ставит. Вам надо заранее разобраться, что у него болит, чего он хочет.

Основная презентация и предложение о покупке

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

Строим презентацию по схеме:

• Как ваша идея поможет собеседнику?

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

• Визуализируем ужасное будущее;

• Визуализируем хорошее будущее;

• Если это нужно, даем МИНИМУМ технических деталей;

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

• Называем цену.

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

Очень хорошая фраза, которая отдает мячик вашему собеседнику после презентации:

Мне кажется, это хорошая идея. Что скажешь?

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

Перенаправление на рост уверенности.

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

• Спросите, что смущает, и развейте страх

Если у вас не купили, значит, нет уверенности. Надо выяснить, где провал, почему 50% вместо 100%. И постараться это починить. Возможно, собеседник скажет напрямую:

• Я не уверен, что это поможет.

Об идее, скорее всего, можно говорить прямо. Но вряд ли человек скажет:

• Я тебе не доверяю, как специалисту.

Или:

• Мне кажется, твоя команда не справится.

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

Снижение порога действия

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

Итак, на предыдущем этапе во всех трех пунктах набралось по 100 баллов, мы молодцы, идея классная, она нравится нашему собеседнику. Однако ему нужно совершить очень много действий, чтобы реализовать озвученную идею. Например, вы предложили ему что-то автоматизировать, но для этого он, дорогой ваш владелец бизнеса, должен подать заявку, чтобы она прошла через бюрократическую систему. Ему проще сказать: Да ну его на фиг! и убежать, чем соглашаться на такую длинную историю.

Поэтому вы должны постараться обеспечить легкий вход, например:

• Просто кивни, мы все сделаем сами.

• Тебе ничего не надо будет делать.

• Мы уже попробовали, и вот результат...

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

Усиление боли

Это визуализация страшного будущего, в котором ваш собеседник не согласился на вашу идею:

• Если ничего не поменяется, то...

• Знаешь ли ты, что будем, если мы этого не сделаем?

• Через год станет

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

Закрытие сделки

Это опять передача мяча собеседнику:

• Что дальше?

• Ну что, попробуем?

• Ты согласен, что...?

Это прямые вопросы, которые вы задаете собеседнику: Ну, как? Берем работу в следующий спринт? Ставим в план на следующий месяц?. Но эти вопросы часто просто забывают задать. Мы вроде бы обсудили идею и просто ждем, когда человек сам скажет: Ладно, давай. Я буду делать то-то и то-то.

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

Пример

В 2015 году в одной из команд Алексей работал как техлид и на этапе подготовки он узнал о том, что сроки выхода в продакшн жестко зафиксированы, а в SLA на починку ошибки в продакшн выделено всего три дня.

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

Диалог был примерно такой:

• Привет! Я хочу обсудить одну техническую задачу, которая может ускорить время разработки задач и починки ошибок. Есть 10 минут, чтобы обсудить сейчас?

• Давай.

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

Дальше идет презентация:

Смотри, сейчас у нас нет автотестов, и каждую фичу перед выпуском мы тестируем руками, ЭТО ДОЛГО. Я с ребятами УЖЕ ПОСЧИТАЛ, что если мы закроем 15% функционала тестами, то разработка каждой новой фичи УСКОРИТСЯ НА 2 ДНЯ. Благодаря этому мы сможем сделать на 10 фич больше до дедлайна. Мы все сделаем сами, надо просто взять в этот и следующий спринты задачи по разработке тестов. За этот месяц мы сделаем меньше фич, НО зато потом каждую будем делать быстрее. А еще это поможет быстрее чинить баги.

Что мы здесь видим? Во-первых, в презентации были указаны конкретные цифры. 15% функционала, 2 дня и 10 фич.

Во-вторых, был минимум технических деталей, а конкретно одна: 15% функционала надо закрыть. Цифра на самом деле не важна это может быть и 10%. Владельцу продукта важнее, что разработка новой фичи ускорится, или что баги будут чиниться быстрее.

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

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

В оригинале презентация была долгой, встреча на час. И одна из фраз, которая там прозвучала:

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

• Что скажешь?

Это пример, как можно по такому алгоритму проводить продажи идей.

Полезные фишки

Есть полезные фишки, которые помогут в любом диалоге:

• НО наоборот;

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

• Потому что;

Если вы просто говорите: Так, дорогой мой бизнес, надо сделать рефакторинг и точка!, вам ответят: Да иди ты со своим рефакторингом! Почему? Вы не объясняете собеседнику причины. Людям гораздо легче согласиться с вами, когда они понимают, зачем вы это делаете. бъясните, зачем вы продаете идею (возвращаемся к целям и выгодам). Если вы пришли с идеей без объяснений, почему это важно сделать, то ваш собеседник почувствует себя обескураженным, не зная нужных ему деталей. Объясняя, вы выравниваете диалог.

• Визуализация;

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

• Двойная петля;

Если вы видите, что собеседник сомневается (сначала у него есть один аргумент против, потом появляется другой, третий), скажите ему прямо: Мне кажется, что ты не уверен в идее, которую я принес. Расскажи, почему?. Так он попадает в двойную петлю: либо говорит: Нет-нет, я уверен, и начинает сам себе продавать уверенность, либо говорит: Да, я не уверен, и тогда дает вам аргументы, с которыми вы сможете работать.

• Прямолинейность.

То, что вы честно и открыто ведете диалог, всегда подкупает.

Подводя итог

Итак, чтобы договориться, нужно выполнить несколько важных условий.

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

Кроме того, вы должны добиваться 100% уверенности по трем пунктам: в продукте, который продаете, в вас, как эксперте, и в людях, кого представляете.

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

TechLead Conf 2021 пройдет 30 июня 2021и 1 июля 2021 в московской Radisson Slavyanskaya. Расписание можно посмотреть здесь.

Билеты на конференцию вы можете приобрести уже сейчас. Спешите: 1 мая цена станет выше!

Однажды Энтони Феррара (Anthony Ferrara) решил скомпилировать PHP в низкоуровневый код, но результат получился слабым. Главной проблемой, с которой он столкнулся, было отсутствие подходящего бэкенда. К лучшему все изменилось после того, как в дело вступил FFI.

Я советую прочитать статью A PHP Compiler, aka The FFI Rabbit Hole, перевод который вы найдёте под катом.

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

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

Виды компиляторов

Существуют три основных способа выполнения программ.

• Интерпретация: подавляющее большинство динамических языков (например, PHP, Python (CPython), Ruby и т. д.) можно интерпретировать с помощью какой-либо виртуальной машины.

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

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

• Компиляция: значительная часть языков, которые мы считаем статическими, компилируется заранее (ahead of time, AOT) прямо в нативный машинный код. Многие языки (C, Go, Rust и т. д.) используют AOT-компилятор.

Суть AOT в том, что вся компиляция происходит целиком до выполнения кода. Это значит, что вы сначала компилируете код и через некоторое время выполняете его.

Основное преимущество AOT-компиляциигенерация очень эффективного кода, а главный недостатокдлительность компиляции.

• Just In Time (JIT): JIT относительно недавно стал популярным методом, благодаря которому можно взять лучшее от виртуальной машины и AOT. Многие языки программированияLua, Java, JavaScript, Python через интерпретатор PyPy, HHVM, PHP 8 и прочиеиспользуют JIT.

В сущности, JITпросто сочетание виртуальной машины и AOT-компилятора. Вместо того, чтобы компилировать всю программу за раз, он выполняет какую-то часть кода на виртуальной машине. Такая компиляция преследует две цели:

1) выяснить, какие части кода горячие, а значит, наиболее полезны для компиляции в машинный код;

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

Затем JIT-компилятор ненадолго приостанавливает выполнение кода, чтобы скомпилировать только эту небольшую часть в машинный код. JIT попеременно то интерпретирует исходный код, то выполняет скомпилированный.

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

Подытожим:

• интерпретатор выполняет код;

• AOT-компилятор генерирует машинный код, который потом выполняет компьютер;

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

Немного объяснений

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

• Компилятор: значение термина компилятор зависит от контекста.

Если мы говорим о сборке рантаймов языков программирования (эти рантаймы тоже называют компиляторами), то компиляторпрограмма, которая преобразовывает код из одного языка в другой с отличной от него семантикой. Это не просто иное представление кодакод именно преобразовывают. Примеры такого преобразования: из PHP в опкоды, из C в промежуточное представление, из ассемблера или регулярного выражения в машинный код. Да, в версии PHP 7.0 есть компилятор, который компилирует исходный код языка PHP в опкоды.

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

Да уж, запутано...

• Виртуальная машина (VM): я упомянул выше, что виртуальная машинагигантский switch в цикле. Чтобы понять, почему ее называют виртуальной, давайте немного поговорим о том, как работает настоящий физический CPU.

Настоящая машина выполняет команды, закодированные в нули и единицы. Эти команды можно представить как код ассемблера:

Этот код просто добавляет 1 к регистру rsi, затем добавляет к нему 2.

Посмотрите, как та же операция представлена в опкодах PHP:

Если не принимать во внимание соглашение об именах, то можно сказать, что по сути они равнозначны. Опкоды PHPкоманды-кирпичики для виртуальной машины PHP, а ассемблерто же самое для CPU.

Разница в том, что команды ассемблера очень низкоуровневые, и их сравнительно немного, в то время как в команды опкода виртуальной машины PHP встроено больше логики. В примере команда ассемблера incq ожидает аргумент в виде целого числа. С другой стороны, опкод POST_INC содержит всю логику, необходимую для того, чтобы сначала преобразовать аргумент в целое число. В виртуальной машине PHP гораздо больше логики, что в свою очередь:

а) делает существование PHP и любого интерпретируемого языка возможным,

б) становится главной причиной того, что интерпретируемые языки часто используют VM.

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

• Дерево абстрактного синтаксиса (Abstract Syntax Tree, AST): ASTвнутренняя структура данных, которая представляет исходный код программы в виде дерева. Таким образом, вместо $a = $b + $c; получаем что-то вроде Assign($a, Add($b, $c)). Главная характеристика деревау каждого узла только один родитель. PHP выполняет внутреннее преобразование исходного файла в AST перед компиляцией в опкоды.

Если дан следующий код:

то можно ожидать, что AST будет выглядеть так:

• Граф потока управления (control flow graph, CFG): CFG во многом похож на AST, но если у первого может быть несколько корневых элементов, то у второго только один. Это можно объяснить так: CFG включает в себя связи между циклами и т. п., так что можно увидеть все возможные пути управления, проходящие через весь код. Расширение Opcache Optimizer для PHP использует внутри CFG.

Если дан следующий код:

то можно ожидать, что CFG будет выглядеть так:

В этом случае longцелое число PHP, numericцелое число или число с плавающей запятой, jumpzпереход к другой команде в зависимости от того, равна ли bool_21 0 или нет.

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

• Промежуточное представление (Intermediary Representation, IR): IRязык программирования, который полностью живет в компиляторе. Вы никогда не будете писать на этом языке, его для вас генерируют. Тем не менее, стоит отметить, что IR нужен для некоторых манипуляций компилятора (например, для реализации оптимизаций), а также для того, чтобы компоненты компилятора были разделены (в итоге их легче настраивать). Вышеупомянутые структуры AST и CFGформы IR.

Немного предыстории

Я впервые попытался выполнить PHP поверх PHP в рамках проекта PHPPHP еще в 2013 году. Суть проекта состояла в том, чтобы перевести исходный код из репозитория php-src с языка C на PHP. Не было и речи о том, что виртуальная машина будет работать быстро (слово быстро в кавычках, так как эта машина примерно в 200 раз медленнее, чем PHP, и нет никакого способа ее разогнать). Я просто развлекался, мне нравилось экспериментировать и учиться чему-то новому и интересному.

Полтора года спустя я создал набор инструментов Recki-CT, который работал по иной схеме. Вместо того, чтоб реанимировать прошлую попыткуPHP в PHP, я создал многоступенчатый компилятор. Он парсил PHP в AST, преобразовывал AST в CFG, проводил оптимизацию, затем выдавал код через бэкенд. Для этой задачи я собрал два начальных бэкенда: один компилировал код в расширение PECL, а второй использовал расширение JitFu для непосредственного выполнения кода, оперативно компилировал его и запускал в виде нативного машинного кода. Эта реализация работала довольно неплохо, но была мало применима на практике по ряду причин.

Несколько лет спустя я снова вернулся к этой идее, но решил не создавать единый монолитный проект, а заняться серией взаимосвязанных проектов по парсингу и анализу PHP. В рамках этих проектов были реализованы следующие инструменты: PHP-CFGпарсинг CFG, PHP-Typesсистема вывода типов, PHP-Optimizerбазовый набор оптимизаций поверх CFG. Я разработал эти инструменты для того, чтобы встроить их в другие проекты для различных целей (например, Tuliранняя версия статического анализатора кода PHP). В проекте PHP-Compiler я пытался компилировать PHP в низкоуровневый код, но результат получился слабым.

Главной проблемой, с которой я столкнулся при создании полезного низкоуровневого компилятора, было наличие (точнее отсутствие) подходящего бэкенда. Библиотека libjit (используемая расширением JitFu) работала хорошо и быстро, но не могла генерировать бинарники. Я мог бы написать расширение на C, привязанное к LLVM (HHVM использовала инфраструктуру LLVM и многие другие), но это ОЧЕНЬ трудозатратный процесс. Я не захотел идти этим путем и отложил эти проекты до лучших времен.

В игру вступают PHP 7.4 и FFI

Нет, версия PHP 7.4 еще не вышла (Пост был опубликован в 22 апреля 2019 года). Возможно, она будет выпущена через полгода. Несколько месяцев назад небольшое предложение по включению расширения FFI в PHP успешно прошло голосование. Я решил поиграть с этим расширением, чтобы узнать, как оно работает.

Спустя некоторое время я вспомнил о своих проектах, связанных с компиляторами. Я стал думать, насколько сложно будет загрузить libjit в PHP, но затем сообразил, что эта библиотека не может генерировать исполняемые файлы. Я начал искать возможные варианты решения проблемы и наткнулся на библиотеку libgccjit. Так началось мое путешествие по кроличьей норе.

Вот все новые проекты, над которыми я работал последние несколько месяцев.

FFIMe

Мой первый шагсоздание обертки над libgccjit. FFI требует заголовочный файл, похожий на C, но сам не может обрабатывать макросы препроцессора C. Непонятно? Ок, просто знайте, что у каждой библиотеки есть по крайней мере один заголовочный файл, который описывает функции, и FFI нужна его сокращенная версия.

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

Встречайте FFIMe.

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

По сути, FFIMe получает путь к Shared Object File и к директивам #include. Он парсит получившийся С, убирает несовместимый с FFI код и затем генерирует класс. Хорошо, МНОГО классов. Теперь сгенерированный файл можно рассмотреть (файл из примера выше на GitHub).

Если вы посмотрите на этот файл, то увидите ОГРОМНОЕ количество кодапочти 5000 строк. Он включает в себя все числовые #define заголовков C как константы класса, все ENUM как константы класса, а также все функции и классы-обертки всех базовых типов C. Файл также рекурсивно содержит все другие заголовки (поэтому у заголовка выше есть некоторые на первый взгляд лишние файловые функции).

Код использовать весьма просто. Примечание: не обращайте внимание на то, что делает библиотека, просто смотрите на типы и на вызовы, затем сравните с эквивалентным кодом на C:

Теперь можно работать с библиотеками C в PHP как будто бы они в C! Ура!

Стоит отметить, что, несмотря на некоторые недоработки FFI, которые позже были исправлены, работать с ним довольно просто. Неплохая альтернатива погружению в дебри PHP (кхе-кхе). Дмитрий Стоговавтор FFI для PHPпроделал великолепную работу.

PHP-CParser

Сделав рефакторинг FFIMe, я решил собрать полнофункциональный C parser. Он работает так же, как PHPParser разработчика Никиты Попова, но не в PHP, а в C.

Пока поддерживается не весь синтаксис C, но PHP-CParser использует стандартную грамматику C, так что теоретически он способен парсить все без исключения.

В начале препроцессор C обрабатывает заголовочные файлыон резолвит все стандартные директивы, такие как #include, #define, #ifdef и т. д. Потом PHP-CParser парсит код в AST (по мотивам CLANG).

Таким образом, например, следующий код C:

и includes_and_typedefs.h:

даст такой AST:

Синие именаимена классов объектов, а красные имена в нижнем регистреимена свойств указанных объектов. Так, внешний объект здесьPHPCParser\Node\TranslationUnitDecl с массивом свойств declarations. И так далее...

Очень редко кому-то надо парсить код C в PHP, поэтому я полагаю, что эту библиотеку будут использовать только с FFIMe. Но если вы захотите ее использоватьвперед!

PHP-Compiler

Я вернулся к проекту PHP-Compiler и начал работу над ним. В этот раз я добавил несколько этапов к компилятору. Я решил не компилировать непосредственно из CFG в нативный код, а применить Virtual Machine interpreter (именно так и работает PHP). Это ГОРАЗДО более зрелый подход, чем тот, который я использовал в PHPPHP. Я не остановился на этом и создал компилятор, который может брать опкоды виртуальной машины и генерировать нативный машинный код. Это позволило применить как JIT-компиляцию (Just In Time), так и AOT-компиляцию (Ahead of Time). Таким образом, я могу не только запускать код или компилировать его во время запуска, но и предоставить компилятору кодовую базу для того, чтобы он сгенерировал файл машинного кода.

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

Я начал собирать PHP-Compiler поверх libgccjit и получил весьма интересные результаты. Простой набор бенчмарков, взятых из пакета PHP, показывает, что хотя сейчас и есть МНОГО накладных расходов, скомпилированный код может быть действительно блестящим.

Следующие тесты сравнивают производительность PHP-Compiler, PHP 7.4 с OPcache (Zend Optimizer) и без него, а также экспериментального JIT (в включенном и выключенном состоянии) для PHP 8.

Заметен ощутимый простой при старте (помните, это PHP!). Однако компиляция кода (как в режиме JIT, так и в режиме AOT) происходит значительно быстрее, чем в PHP 8 с JIT-компиляцией в особо сложных вариантах использования.

Стоит отметить, что мы сравниваем совершенно разные вещи. Не стоит ожидать такие же показатели в продакшен-проектах, но по ним можно сделать вывод о перспективности такого подхода...

Сейчас можно использовать эти 4 команды:

• php bin/vm.phpзапустить код в виртуальной машине;

• php bin/jit.phpкомпилировать весь код, затем запустить его;

• php bin/compile.phpкомпилировать весь код и вывести файл a.o;

• php bin/print.phpкомпилировать и вывести CFG и сгенерированные опкоды (полезно для отладки).

В командной строке все работает как PHP:

Да, здесь echo "Hello World\n"; работает как нативный машинный код. Перебор? Определенно. Прикольно? Однозначно!

Подробности в описании проекта.

Я приостановил сборку, потому что не знал, стоит ли и дальше использовать libgccjit или лучше перейти на LLVM?

Есть только один способ выяснить это...

PHP-Compiler-Toolkit

Как вы уже поняли, я не умею давать названия вещам...

PHP-Compiler-Toolkitуровень абстракции поверх libjit, libgccjit и LLVM.

Вы просто встраиваете код, похожий на код языка C, в кастомное промежуточное представление через нативный интерфейс PHP. Например, это выражение (обратите внимание, что long long 64-битное целое число, как и тип PHP int):

можно использовать так:

Это описывает код. Отсюда можно передать контекст бэкенду для компиляции:

и потом просто получить в ответ:

Вот мы и получили чистый нативный код.

Теперь я могу собрать фронтенд (PHP-Compiler) поверх этой абстракции и менять бэкенды для тестирования.

Выходит, что тестирование было хорошей идеей, потому что первые прогоны показывают, насколько медленно работает libgccjit в этой конфигурации. Замеры компиляции:

Хотя все бэкенды и имеют сравнимые показатели в рантайме, продолжительность компиляции для libgccjit зашкаливает. Хм, может я был прав, когда думал перейти на LLVM?..

Да, и для такой простой функции накладные расходы FFI весьма значительные. На запуск этого же кода в PHP уходит примерно 0,02524 секунды.

Чтобы продемонстрировать, что PHP-Compiler может в перспективе работать гораздо быстрее, чем PHP, представьте себе такой бенчмарк:

В нативном PHP запуск этого кода миллион раз займет примерно 2,5 секунды. Не то чтобы медленно, но и не супер быстро. Однако с PHP-Compiler мы видим следующее:

В этом искусственном примере можно увидеть десятикратный прирост производительности по сравнению с нативным PHP 7.4.

Вы можете посмотреть этот пример и скомпилированный код в examples folder of php-compiler-toolkit.

PHP-LLVM

После проекта PHP-Compiler-Toolkit я начал работу над PHP-LLVM. Эксперименты с Toolkit показали, что у libgccjit нет реальных преимуществ перед LLVM, у которой есть преимущества в производительности и функциональности, поэтому я решил перевести PHP-Compiler исключительно на нее.

Я не стал обращаться непосредственно к LLVM C-API, а написал обертку над ним. Я преследовал две цели:

1) я получаю более объектно-ориентированный API, так как, чтобы получить тип значения, пишу $value->typeOf(), а не LLVMGetType($value);

2) с оберткой я могу не обращать внимание на различия в версиях LLVM.

Таким образом, в идеале можно добавить поддержку различных версий LLVM и проверить, поддержка каких возможностей реализована.

PHP-ELF-SymbolResolver

Стоит отметить, что в LLVM были ошибки, поэтому мне нужно было видеть, какие символы на самом деле компилируются в LLVM.Таким образом, я хотел проверить общий файл объекта (.so), который содержит скомпилированную библиотеку LLVM. Для этого я написал PHP-ELF-SymbolResolver, который парсит файлы формата ELF и показывает объявленные символы.

По определенным причинам я сомневаюсь, что этот проект будет востребован вне FFIMe, но, возможно, кому-то будет нужно декодировать нативную библиотеку ОС в PHP. В таком случае вы знаете, где взять библиотеку!

Использование макросов

Портируя PHP-Compiler на PHP-LLVM, я понял, что генерация кода с использованием API как билдера быстро становится многословной. Код невозможно прочитать. Например, возьмем сравнительно простую встроенную функцию __string__alloc, которая определяет новую внутреннюю структуру строки. Если использовать API как билдер, то она будет выглядеть примерно так:

Просто куча мусора. Трудно понять что-либо, а если какую-то часть кода и можно прочитать, то с ней очень сложно работать).

Чтобы избежать такого результата, я написал систему макросов с помощью PreProcess.ioиYay. Теперь тот же код выглядит так:

Читать код стало гораздо легче. Это смесь синтаксиса C и PHP, заточенная под нужды PHP-Compiler.

Язык макросов частично задокументирован на GitHub-е.

Подробности о применении макросов смотрите на src/macros.yay (GitHub).

Беспокоитесь о производительности? Правильно делаете. На обработку файлов нужно время (примерно одна секунда на файл). Есть два способа борьбы с этим:

1) предварительная обработка возможна только при установке PHP-Compiler с dev-зависимостями с помощью композера, иначе будут загружены только скомпилированные файлы PHP;

2) предварительная обработка произойдет на лету только при изменении файла .pre, даже с dev-зависимостями.

В итоге накладные расходы в режиме разработки несущественны, а в продакшене их просто нет.

Запуск

Сначала установите PHP 7.4 с включенным расширением FFI. Насколько мне известно, эта версия PHP еще не вышла (и до того, как выйдет, пройдет еще немало времени).

Запуск FFIMe:

Объявите FFIMe dev-зависимостью композера ("ircmaxell/ffime": "dev-master") и запустите генератор кода через файл стиля rebuild.php. Например, файл rebuild.php, используемый PHP-Compiler-Toolkit, выглядит так:

Потом сравните сгенерированные файлы. Я предлагаю включать сгенерированные файлы через композер с ключевым словом files, а не загружать их автоматически, потому что композер сгенерирует ОГРОМНОЕ количество классов в один файл.

Замените строку "...so.0" путем к общей библиотеке, которую вы хотите загрузить, и файл .h заголовками, которые нужно парсить (можно много раз вписать ->include()).

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

Запуск PHP-Compiler нативным образом

Сейчас PHP-Compiler работает нестабильно, что-то может ломаться, поэтому сначала установите зависимости (можно использовать LLVM 4.0, 7, 8 и 9).

После окончания установки просто запустите их.

Вы можете задать выполнение в командной строке, используя аргумент -r:

Еще можно задать файл:

При компиляции bin/compile.php также можно задать выходной файл с -o (по умолчанию будет перезаписан исходный файл без расширения .php). Для системы будет сгенерирован готовый к выполнению бинарник:

Или по умолчанию:

Список поддерживаемого будет очень часто меняться. Код, который работает сегодня, может не работать на следующей неделе. Сейчас реализована поддержка для очень небольшого числа версий PHP...

Запуск PHP-Compiler с Docker

Удобства ради я опубликовал два docker-образа для PHP-Compiler. Оба основаны на старой версии Ubuntu (16.04) из-за некоторых проблем с PHP-C-Parser, до которых у меня не дошли руки. Но вы можете скачать их и поиграть с ними:

• Ircmaxell/php-compiler:16.04полнофункциональный компилятор, полностью установленный и сконфигурированный со всем необходимым для его запуска;

• Ircmaxell/php-compiler:16.04-devтолько dev-зависимости. Контейнер предназначен для работы с вашей собственной сборкой PHP-Compiler, чтобы вы могли разрабатывать его в стабильной среде.

Для запуска кода:

Код будет по умолчанию запущен с bin/jit.php. Если вы хотите запустить код с другой точки входа, то ее можно изменить:

Да, и если вы хотите передать скомпилированный код, то можно расширить docker-файл. Например:

Во время запуска сборки docker код будет скомпилирован в index.php, а файл машинного кода будет сгенерирован в /app/index. Затем этот бинарник будет выполнен при запуске docker run ..... Обратите внимание: контейнер не предназначен для продакшена, так как в нем много лишнего, это просто демонстрация работы.

Что дальше

Теперь, когда PHP-Compiler поддерживает LLVM, можно продолжать работу по расширению поддержки языка. Еще многое предстоит сделать:например, массивы, объекты, нетипизированные переменные, обработку ошибок, стандартную библиотеку и т. д.). Хе-хе. В PHP-CFG и PHP-Types также есть, чем заняться: поддержкой исключений и ссылок, исправлением пары ошибок и многим другим.

Да, нужны тесты. Много тестов. И тестировщики. Пробуйте, ломайтеэто легко, обещаю. И создавайте ишью.

Протестируете?

PHP Russia 2021пройдет28 июнявМосква, Radisson Slavyanskaya. Но уже сейчас можно ознакомиться срасписаниеми присмотреть доклады, которые вы точно не захотите пропустить.

А еще вы можете выбрать формат участия: онлайн или офлайн. Не забудьтекупить билетыуже сегодня!

На всех наших офлайн площадках мы соблюдаем антиковидные меры:

1. Все сотрудники конференции сдают тест ПЦР и ходят в масках.

2. Участникам выдаём комплект медицинских масок и санитайзеры.

3. Во всех помещениях конференции и в фойе работают мощные рециркуляторы воздуха.

4. Каждый микрофон мы протираем спиртовыми салфетками, прежде чем передать его участнику.

5. В зоне кофебрейков и обедов соблюдаются нормы социальной дистанции.

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

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

Генеративно-состязательная нейронная сеть (Generative adversarial network, сокращенно GAN) научилась выявлять индивидуальные стандарты красоты при помощи ЭЭГ участников эксперимента. Статья об этом опубликована в журнале IEEE Transactions in Affective Computing.

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

До эксперимента финских ученых нейросети уже многому успели научиться. Например, при помощи PG GAN от nVidia можно создать потрясающе реалистичные изображения людей, которых на самом деле не существует на свете:

А алгоритм Everybody Dance Now позволяет на основе видео с танцором сгенерировать фейковую запись, на которой другой человек будет повторять те же движения.

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

Однако создать изображение лица, которое будет красивым для конкретного человека, дол.гое время не удавалось.

Авторы исследования из Хельсинкского университета считают, что субъективно привлекательность зависит от неявной обработки определенных черт. Причем, у каждого человека они свои. По их мнению, генеративно-состязательные нейронные сети потенциально способны смоделировать субъективные предпочтения, не опираясь на заранее заданные параметры.

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

Как сообщает N+1, в исследовании финских ученых, объединяющем информатику и психологию, приняли участие 30 сотрудников и студентов Хельсинкского университета.

В эксперименте использовался так называемый метод потенциала, связанного с событием (ПСС). Этот метод позволяет измерить отклик мозга на когнитивное или моторное событие (в данном случае на эстетическое эстетическое переживание). Для начала все участники посмотрели восемь серий по четыре изображения и отобрали в каждой из них по одному самому непривлекательному лицу.

Данные ЭЭГ передавались генеративно-состязательной нейросети через интерфейс мозг-компьютер. Это делалось для того, чтобы она могла обучаться создавать индивидуально привлекательные изображения для каждого участника.

Спустя два месяца люди, принимавшие участие в эксперименте, пришли, чтобы оценить его результаты. Пришедшим продемонстрировали матрицу из двух рядов по 12 картинок. Среди изображений, созданных нейросетью, были непривлекательные и нейтральные лица, а также лица предположительно симпатичные определённому человеку. Участникам предложили нажимать на изображения, которые они считали красивыми, а также оценить их по шкале от 1 (очень непривлекательное) до 5 (очень привлекательное).

Эксперимент оказался успешным! 86,7% созданных нейросетью привлекательных изображений изображений, подтвердились предпочтениями людей. Однако, участникам понравились 20% изображений, которые GAN создала в качестве непривлекательных. То есть по результатам исследования, появились ложноотрицательные результаты.

Более высокие рейтинги получили изображения, которые нейросеть создала как привлекательные, в сравнении с нейтральными и непривлекательными. То есть была найдена такая структура данных, которая позволяет разделять реакции мозга на привлекательные и непривлекательные лица. Причем, речь идет о высокой точности совпадений с реальными реакциями людей (83,33%).

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

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

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

КонференцияHighLoad++ 2021пройдет уже 17 и 18 мая в Москве, в Крокус-экспо. У нас готоворасписание, и вы уже сегодня можете запланировать активности!

Билеты можно купитьздесь. С 1 мая цена на них станет выше.

Хотите бесплатно получить материалы мини-конференции Saint HighLoad++ 2020?Подписывайтесьна нашу рассылку.

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

Илья не связан напрямую с исследованиями вокруг коронавируса, но тема эта интересна ему с точки зрения пересечения фармакобизнеса, фундаментальной науки и организации медицины. Разнообразный опыт позволяет Илье посмотреть с разных точек зрения на историю самой крупной эпидемии за последнее столетие. 9 лет после окончания медфака ПетрГУ Илья посвятил научным исследованиям в области нейробиологии в лаборатории Хельсинкского университета и в компании, которая делает исследования для крупной фармы. С 2014 года Илья работает в Университетской клинике Хельсинки, где начинал как врач общей практики, а сейчас специализируется на судебной психиатрии.

Беседа получилась интересной: Илья сумел объяснить самые сложные вещи простым языком, через понятные образы.

Илья, первый вопрос, наверное, самый важный для нас: есть ли вообще свет в конце тоннеля? Проглядывается он в России, в Европе?

Я хуже знаю ситуацию в России, чуть лучше в Европе. И очень надеюсь, что летомосенью будет снижение заболеваемости. Потому что прошлом году в Европе вирус показал очевидную сезонность. Летом практически нигде в Европе не было взрывных случаев, они были чуть ли не единичные. Может быть, сотни случаев заражений на всю Европу. Показатели снова начали расти в начале осени 2020 года. Я думаю, если Европа успеет привиться за лето (а похоже, что Европа успеет), то всё может закончиться летомосенью. И новой волны осенью не будет.

Насчёт России всё очень неоднозначно. Есть такой R-коэффициент. Он показывает, сколько в среднем один заражённый человек заражает на данный момент других людей:

• Если R = 1, то один заражённый заразил одного здорового. Это значит, что эпидемия ни растет, ни падает.

• Если R > 1, то эпидемия растет (а растёт она всегда экспоненциально). Даже если R = 1.01, она просто медленно экспоненциально растет.

• Если R < 1, то эпидемия падает.

В России есть регионы, в которых R-коэффициент выше 1. А привито сейчас чуть больше 6% населения. Для сравнения, Германия и Франция стремятся к 20%, Финляндия уже перешла за 20%, в Англии привили почти 50%, в Израиле 60%. Если не учитывать детей (сейчас прививают в основном взрослых) получается, что в Израиле привито больше 80% взрослого населения.

Источник изображения: https://ourworldindata.org/covid-vaccinations

В России прививок делается мало, процесс идёт медленно. Если посмотреть Германию и Францию, то они шли медленно, а в последнее время ускорились. Россия идёт линейно, не особо ускоряясь. Может, на таких масштабах мы не замечаем этого ускорения, но взрывного роста вакцинации в России пока не видно.

Второй момент. Для группового иммунитета не очень важно, получил человек иммунитет с вакциной или переболел. Большой вопрос, сколько переболевших людей в России. Нет хороших исследований, разные источники дают разные цифры. Но оценка, которая мне кажется правдоподобной это порядка 30-40% переболевших. Чтобы эпидемия закончилась, нужно чтоб переболело около 70% населения. Если за лето большая часть россиян не привьётся, то можно ожидать резкий рост заболеваемости осенью.

Источник изображения: http://91-divoc.com/pages/covid-visualization/

Насколько я понимаю, иммунитет от COVID-19 не пожизненный. Тогда как оценить порог в 70%? Получается, что мы будем болеть бесконечно, потому что люди будут заболевать снова и снова. Кто-то уже переболел коронавирусом 2-3 раза. Или есть шанс, что мир (и Россия в том числе) перейдет один раз через этот порог и эпидемия, как минимум, сильно замедлит темпы?

Хороший вопрос. Здесь несколько факторов.

Фактор номер раз. То, что антитела временно действуют, не совсем правда. Ветрянкой и корью мы болеем один раз и потом у нас на всю жизнь иммунитет от них. Оспу нам привили когда-то один раз, и все больше не нужно прививаться. Вакцина против столбняка действует 10 лет. Есть мнение, что от коронавируса нам нужно будет прививаться каждый год. Но пока мы не знаем, насколько стойкий иммунитет будет от SARS-Cov-2. Точнее, насколько стойкий иммунитет дают коронавирусные вакцины, которые сейчас есть на рынке.

РНК-вакцины вообще впервые использовали в клинических испытаниях примерно 9 месяцев назад. Первый раз в истории человечества используются вакцины такого типа! Иммунитет от них всё ещё держится. 9 месяцев, полёт нормальный. Сколько он продержится, мы не знаем. Вряд ли он упадет внезапно. Скорее всего, если говорить о пессимистичной оценке, он продержится год-полтора-два. Есть же вирусы, которые вызывают довольно короткий иммунный ответ.

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

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

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

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

Изначально были какие-то группы населения, которые считались более уязвимыми. Это люди старше 65 лет, люди с определенным набором хронических заболеваний, онкобольные и т.д. А потом как-то всё смешалось, и начали болеть люди совершенно разного возраста. Сейчас существует ли такое понятие, как уязвимая группа населения? На данные момент кто в неё входит?

По данным компании Statista шанс умереть от ковида для людей младше 49 лет очень незначительный, но дальше он начинает расти. Для 80+ это уже почти 15%, для 70-79 около 10%. Раньше считалось, что дети не болеют, сейчас уже понятно, что болеют все. Но до сих пор считается, что дети и молодые люди переносят ковид легко, тяжёлые осложнения у них бывают редко.

Но, допустим, миллион молодых людей заболеет, кто-то из них непременно умрёт, потому что 0,2% это не 0. Если пересчитать, то 0,2% от миллиона это 2000 человек, то есть достаточно большое количество людей.

Источник изображения: https://www.statista.com/chart/20860/coronavirus-fatality-rate-by-age/

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

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

Первое предположение ближе к истине пожилых людей привили. Действительно, во всех европейских странах пожилые люди перестали болеть и попадать в больницы.

Второе надо смотреть данные по Кипру. Цифры заболеваемости на Кипре очень большие.

Источник изображения: http://91-divoc.com/pages/covid-visualization/

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

На графике видно, что заболевших намного больше, чем было год назад. Сейчас болеют в основном молодые (мы же помним, что старшее поколение привито). Это не значит, что молодёжь переносит болезнь тяжелее, чем раньше. Просто общее количество заболевших больше. В 2020 году болели, например, 100 человек до 49 лет, и тяжело болел один. Если сейчас их 1000, а значит, и тяжелобольных уже 10. Это сказывается и на ситуации в больницах.

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

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

В принципе, всегда, когда мы сдаем тест, мы должны думать зачем? Просто так сдавать тест не имеет большого смысла. Если вам этот результат зачем-то нужен, смысл есть.

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

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

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

Есть такое понятие театр безопасности. Это когда мы что-то такое делаем, и как будто чувствуем себя в безопасности. Проблема с масочными исследованиями в том, что их довольно трудно сделать. Представьте вы считаете, что маски, скорее всего, помогают, и ради эксперимента должны заставить половину людей их не носить. Насколько это этично Или вы начали исследование, а у вас поменялась эпидемиологическая ситуация. Как проследить, правильно люди носили маски или нет? Тем не менее, по поводу масок есть исследования, указывающие на то, что они эффективны. Поэтому научный консенсус по маскам есть: они наиболее эффективно защищают от передачи вируса вирус другому человеку и в некоторой степени от того, чтобы получить вирус.

В одном из самых серьезных научных американских журналов Proceedings of the National Academy of Sciences (PNAS) недавно вышел большой обзор, который суммирует эти данные и говорит, что маски помогают.

Я работаю в Хельсинки в университетской клинике. Проблема с масками решилась здесь мгновенно. У нас отслеживаются все ситуации заражения с самого начала вируса, особенно в больнице.

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

Здорово, хоть что-то успокоительное мы знаем про коронавирус! Спасибо. А что насчет перчаток?

А перчатки не нужны это глупость.

А почему перчатки глупость? Я читала, что они могут быть даже грязнее, чем руки. Потому что всё-таки руки мы почаще моем, чем стираем перчатки. Это так?

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

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

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

Я примерно представляю, откуда у этого мифа растут ноги. Из наблюдений, которые были сделаны во времена предыдущей пандемии (испанка в 1918 году). Тогда действительно было замечено, что в городах, где заболевших было мало в первую волну, в следующий сезон заболеваемость была очень большая.

Но в случае с испанкой есть логичное объяснение: болели практически все, очень мало было действенных ограничительных мер. Поэтому когда в регионе переболела куча людей, образовался групповой иммунитет, и в следующем сезоне регион легче перенёс очередную волну пандемии.

С ковидом это не так. Есть страны, которые больно ударило дважды. Есть страны, где первый раз было легко, а второй тяжело. Например, так было в Чехии. А вот Финляндия перенесла и первую и вторую волну примерно одинаково, в Швеции много людей переболело и в первую, и во вторую волну.

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

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

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

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

В Финляндии это работает. Здесь в начале марта ввели запрет на работу ресторанов, баров и спортзалов, то есть практически всех необязательных точек. На графике отлично видно, как всё пошло вниз после этого.

Источник изображения: http://91-divoc.com/pages/covid-visualization/

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

Существует ли сейчас лекарство с доказанным действием, которым можно лечить ковид? Год назад, конечно, была полная паника и неразбериха с этим.

Насколько понимаю, сейчас в широкой клинической практике нет работающих противовирусных препаратов от ковида с доказанным действием. Что-то сейчас испытывают. Но есть другие препараты, которые используют при ковиде, и они сильно изменили прогноз. Год назад мы совершенно не умели лечить ковид, а сейчас как-то научились. Используются препараты вроде метилпреднизолона, влияющие на иммунную систему и снижающие её активность. Это бывает нужно, чтобы гиперактивация иммунной системы, так называемый цитокиновый шторм, не привел к смерти пациента.

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

И третье. Некоторое время тому назад заговорили про моноклональные антитела. Это когда мы в пробирке создаем антитела к ковиду, которых в организме ещё нет, и вводим их человеку. Про них я не готов сказать, они не пришли ещё в широкую клиническую практику. По идее они должны быть эффективны. Я не очень понимаю, почему их сейчас широко не используют. Возможно, такие препараты дороги и сложны в производстве, поэтому их не очень много. Их кололи Трампу, когда он заболел. (Прим. ред. В феврале 2021г. в США было разрешено использование нескольких препаратов на основе моноклональных антител для лечения ковида у взрослых и детей старше 12 лет).

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

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

Вакцина это точно не чипирование. В Европе все очень просто за тебя решают регуляторы.

Я как врач первую прививку получил уже давно, это была AstraZeneca. Это векторная аденовирусная вакцина, про которую теперь известно, что она вызывает тромбозы у исчезающе малой доли привитых. И сейчас в Европе (во всяком случае в Финляндии) AstraZeneca больше не прививают людей младше 65 лет. Мне вторую дозу уколют, наверное, Pfizer, когда я дождусь. В общем и целом, все вакцины, которые зарегистрированы в Европе и Pfizer, и Moderna, и AstraZeneca действенные и безопасные.

В Англии был проведён анализ, показавший, что только у людей младше 30 лет и только когда эпидемия не очень активна. риск заразиться ковидом и умереть от него, ниже, чем риск неблагоприятных последствий от AstraZeneca. Тут нужно учитывать 2 фактора, когда мы сравниваем: риски от вакцины и риски от самой инфекции. Риск заболеть зависит от того, насколько серьезная эпидемиологическая ситуация. А риск перенести заболевание тяжело зависит в основном от возраста, как мы уже выяснили.

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

По российским вакцинам данных мало. Больше всего мы знаем про Спутник V. Была публикация в Lancet. Её используют в Аргентине, где, как выяснилось, очень хорошо следят за эффективностью вакцин. Оттуда приходят довольно интересные результаты по эффективности, безопасности и всему прочему, чего, к сожалению, нет в России.

СпутникV относится к тому же типу вакцин, что и AstraZeneca это аденовирусная вакцина. Всего сейчас существует три векторных аденовирусных вакцины. Расскажу что это такое. Мы берем аденовирус, который сам по себе вирус, вызывающий простуду, и внутрь этого аденовируса, в его геном, вкладываем кусочек, который кодирует S-белок, то есть фрагмент белка коронавируса. Этот аденовирус при попадании в клетку производит не только все свои белки, которые он должен производить как аденовирус, но еще и S-белок (surfaceprotein поверхностный белок аденовируса). Этот поверхностный белок выходит на мембрану клетки, а там наша иммунная система его встречает и начинает на него отвечать.

Так вот, все эти аденовирусы не способны к размножению. До того, как туда добавить фрагмент ДНК, который кодирует S-белок коронавируса, их изменили так, что сами по себе они не могут размножаться. То есть когда аденовирус попадает в клетку, он там просто умирает. И ничего не делает кроме того, что производит S-белок.

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

Аденовирусных вакцин сейчас на рынке три: AstraZeneca, СпутникV и Janssen (фармакологическое подразделение компании Johnson & Johnson).

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

СпутникV и Janssen используют человеческие аденовирусы. Хитрый Спутник задействовал два аденовируса (первая доза один, вторая доза второй) опять же для того, чтобы иммунный ответ, который выработался после первой дозы, не помешал действию второй дозы.

У вакцины AstraZeneca проявилось осложнение в виде тромбоза и тромбоцитопении. То есть у человека одновременно возникает два противоположных состояния: образуются тромбы и количество тромбоцитов в крови падает. Это уникальная комбинация, обычно у людей такого не бывает, поэтому её быстро и легко связали с вакциной. Проявляется это так: в одной из частей организма активирует процесс свёртывания крови, тромбоциты идут туда и образуют там тромб. Поэтому в кровотоке их становится мало. Грубо говоря мы все тромбоциты собрали, они по стенкам расползлись, их нет в крови. Это и называется тромбоцитопения снижение количества тромбоцитов в крови.

Когда это осложнение заметили в AstraZeneca, подумали, что это обезьяний аденовирус так нехорошо себя ведет. Но потом появилась похожая история с вакциной Janssen. И если с AstraZeneca на 100% понятно, что осложнения связаны с вакциной, с Janssen пока ничего не ясно. Этих осложнений выявили примерно один на миллион. И до конца не понятно, действительно ли они связаны с вакциной Janssen или можно как-то по-другому это объяснить. Но так как все уже обожглись на AstraZeneca, на Janssen начали дуть заранее. Его применение в Америке сразу же приостановили. И пока не будет результатов точных исследований, которые объяснят, что происходит, производитель Janssen решил не проводить вакцинацию.

Соответственно, тут же все начали переживать насчёт СпутникаV. Потому что эта вакцина действует по тому же принципу. Может, такой побочный эффект свойственен всем векторным аденовирусным вакцинам? Со СпутникV есть большая проблема. Не очень понятно, как работает система отслеживания побочных эффектов в России, когда препарат уже на рынке.

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

В случае со СпутникомV у нас мало данных по России, но есть данные из Аргентины. Последнее, что я читал в Аргентине нашли два случая тромбоцитопении. Но тут важно понимать это другое состояние, не тромбоз в связке с тромбоцитопенией.

Есть состояние, которое называется аутоиммунная тромбоцитопения. Оно само по себе достаточно часто встречается. Это просто снижение количества тромбоцитов. В этом случае тромбов не образуется, но у человека повышается риск кровотечения. Потому что тромбоциты нужны как раз для свертывания крови.

К сожалению, то, что пришло из Аргентины, это не научные данные, а только информация о зафиксированных случаях, которые связали с действием СпутникаV. Отчёт Минздрава Аргентины не на английском, и не всё понятно до конца. Но то, что описывается, похоже на обычную аутоиммунную тромбоцитопению. А это другая болезнь, не то же самое, что в случае AstraZeneca.

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

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

Что касается эффективности Спутника, скорее всего, вакцина эффективна. Об этом говорят публикации в Lancet, и данные, которые приходят из Аргентины. Скорее всего, СпутникV безопасен. Никаких повальных случаев и серьёзных проблем мы не видим. И у Спутника пока что не нашли (даже в Аргентине, где, вроде бы, достаточно эффективно отслеживают), побочного эффекта (тромбозов с тромбоцитопенией), который встречается у других векторных вакцин. Побочные эффекты, связанные с тромбоцитопенией, у Спутника менее серьёзные.

Это только моё оценочное суждение, но всем своим родственникам в России я его посоветовал, они все получили вакцину.

Две другие российские вакцины (КовиВак и ЭпиВакКорона) сделаны по другому принципу. КовиВак просто убитый вирус. Это один из самых старых типов вакцин, когда мы берём возбудителя, убиваем его и вкалываем. Такие вакцины, кроме России и Китая, нигде пока не одобрены. Китайские вакцины вроде эффективны, но хороших публикаций по этому поводу нет. Я не могу сказать ничего определённого про эффективность КовиВака или других вакцин этой группы.

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

В общем, если есть выбор, я бы укололся Спутником.

Спасибо. Я тоже убедилась в том, что надо прививаться. В связи с этим вопрос. Нужно ли и обязательно ли важно делать ПЦР до вакцинации?

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

А имеет значение, где прививаться? Сейчас в России, например, есть пункты прививок в торговых центрах.

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

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

Единственное исследование, которое я встречал говорит, что витамин Д помогает легче перенести ковид. По другим витаминам я исследований не встречал.

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

Уточним, что ковид как инфекция заканчивается довольно быстро это не хроническая инфекция, как например, гепатит С. Коронавирус не остаётся в организме годами, месяцами или неделями, как мы себе сейчас это представляем. Сама инфекция проходит достаточно быстро. Но у порядка 20% людей есть так называемый долгий ковид отложенная долгая симптоматика, связанная обычно с утомляемостью и проблемами с дыхательной системой (например, одышка). Этот долгий ковид сейчас исследуется, про него начинают больше понимать.

Ковид может вызывать серьёзные, в том числе, и неврологические осложнения. Последние исследования говорят о том, что примерно 12-13% людей получают, причём впервые после ковида, разного рода психиатрические и неврологические диагнозы: депрессия, тревожные расстройства, инсульты, деменция у пожилых людей, посттравматические стрессовые расстройства.

12-13% это достаточно большая цифра. Коронавирус оставляет шрамы, и эти шрамы бывают разные. Если мы говорим о долгом ковиде, то это симптомокомплекс: длительное утомление, одышка, мышечная слабость, головная боль, субфибрильная температура, когнитивные нарушения. С другой стороны есть, например, психиатрические и неврологические последствия у ковида, к сожалению. Ковид не хроническая болезнь, но он вызывает осложнения, с которыми ещё долго приходится справляться.

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

Это примерно то, о чём я уже говорил. Это выглядит таким образом: есть человек привитый и есть много непривитых заболевших людей. В каждом из этих непривитых заболевших людей вирус мутирует, перескакивая с клетки на клетку. Может случайным образом образоваться мутация, которая потом вернётся к человеку привитому. Допустим, на него чихнуло 10 человек, и у каждого своя мутация. Из этих 10 иммунитет с 9 справился, а один вирус так мутировал, что выполз из-под иммунитета. Его S-белок настолько изменился, что этот вирус антитела больше не узнают. Вирус с такой мутацией вернётся к привитому и, привитый, вроде как, должен заболеть.

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

Как я сказал, есть шанс, что мы будем прививаться раз в год от новых вирусов. Скорее всего, следующие вакцины будут поливалентные. То есть там будет не один S-белок, а 10-20 разных, чуть-чуть отличающихся друг от друга. Чтобы наши антитела были разнообразными и лучше реагировали на будущие или уже присутствующие вариации коронавируса.

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

Давай ещё про аутоиммунные заболевания поговорим. Во-первых, вопрос про прививку: можно ли мне прививаться, если я не вышла в ремиссию?

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

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

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

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

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

Препараты, подавляющие иммунитет нельзя применять как профилактику.

Вопрос по поводу вакцины. Если нет никаких симптомов после того, как человек вакцинировался, это о чем говорит?

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

Специальные молекулы интерлейкины вызывают и местную, и глобальную реакцию. У одного человека, допустим, немножко интерлейкинов выбросилось, но при этом его личная иммунная система выработала огромное количество антител. У другого человека, наоборот, огромное количество интерлейкинов выбросилось, есть серьёзная реакция, а антител не выработалось. В принципе, вакцины, про которые я сейчас говорю (в России Спутник V, в Европе AstraZeneca, Pfizer и Moderna) вызывают иммунный ответ у всех.

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

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

Похоже, что так не происходит. Нет такой субпопуляции людей, у которых не работает российский СпутникV. Обычно наш иммунитет к аденовирусам слабенький, он не успевает сильно убить эту вакцину.

Aденовирусную вакцину вкалывают в дельтовидную мышцу в плечо. Там, до того, как его атакуют антитела, аденовирус быстро заражает мышечные клетки и клетки соединительной ткани. В ответ, эти клетки начинают вырабатывать антигены вируса (S-белок). Он появляется на поверхности клеток, а там уже наши иммунные клетки понимают, что это неродной белок. Начинается выработка антител, которые убивают клетки показавшие на себе чужеродные белок.

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

То есть получается такая закрытая битва в песочнице для обучения наших иммунных клеток?

Да, ровно так. У некоторых людей бывает, что подмышкой может вылезти лимфоузел, это значит, раненые клетки отползли туда.

Может ли эта битва давать какие-то побочные эффекты на другие части нашего тела головные боли, например?

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

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

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

Человеческая популяция живёт, потихонечку на нас запрыгивают разные вирусы. Не думаю, что от того, что мы привили грипп, появился коронавирус. Это не связано никак.

Участников квартирника было не много, так как команда Онтико готовилась к выходу в офлайн (после долгого перерыва это почти как выход в открытый космос). Но слушали целыми семьями. Илья убедил нас в том, что стоит привиться или хотя бы наконец дойти до лечащего врача.

Ближайшая конференция Онтико HighLoad++ 2021 пройдёт уже 17-18 мая в Крокус Экспо. На всех наших офлайн площадках мы соблюдаем антиковидные меры:

• Все сотрудники конференции сдают тест ПЦР и ходят в масках.

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

• Во всех помещениях конференции и в фойе работают мощные рециркуляторы воздуха.

• Каждый микрофон мы протираем спиртовыми салфетками, прежде чем передать его участнику.

• В зоне кофебрейков и обедов соблюдаются нормы социальной дистанции.

Будем рады видеть вас на конференциях 2021 года!

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

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

За мою практику я прочитал немало книг, но некоторые оказали большее влияние на становление разработчиком, а затем управленцем. Я разбил книги по нескольким разделам.

Практика

Книги из практического блока можно просто читать, независимо от того, разработчик вы сейчас или руководитель. Они все классные. Я рекомендую их всем, и они довольно простые прочитали, и можно сразу использовать.

Specification by Example

Книга понравилась мне настолько, что побудила написать первую статью на Хабре. Гойко Аджич автор книги сам описывает ее как книгу о разработке ПО без единой строчки кода. Ее фокус находится на пересечении управления требованиями, проектного менеджмента, DevOps и тестирования (в том числе автоматизированного). Если DevOps часто описывают как infrastructure as code, то Specification by Example это своего рода requirements as code. Проработав некоторое время в корпоративном сегменте индустрии любой разработчик рано или поздно узнает о том, насколько неполными, неточными, противоречивыми и устаревшими бывают требования и насколько сложно, долго и дорого бывает переделывать программы, написанные по таким требованиям. Существуют тяжелые методы борьбы с этим недугом. Например ГОСТ 34 до сих пор используется в госсекторе, несмотря на то, что он безнадежно устарел.

Specification by Example гораздо более гибкая и менее формальная техника, позволяющая, впрочем, заказчику и исполнителю говорить на одном языке, понятном обоим. Кроме того, ГОСТы описывают форму проектной документации, но не дают конкретных советов по проектному управлению и никак не поощряют коммуникацию и совместную работу по улучшению требований и нахождению лучших (более быстрых, качественных и дешевых) способов решения проблем. Примеры переформулированных требований из книги гарантированно не оставят вас равнодушными. Техникой контрольных примеров мы пользуемся уже восемь лет, и она позволяет экономить какое-то невероятное количество времени и избегать недопониманий.

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

Event Storming

Это даже не книга, а своего рода комикс. Если вы любите стикеры, доски и kanban, то event storming скорее всего тоже зайдет. Со временем мы пришли к тому, что большинство web-проектов сразу создаем на основе CQRS-архитектуры, даже если на старте хранилище данных всего одно. Это позволяет по мере развития проектов независимо оптимизировать стеки чтения и записи. И в момент, когда запросы к БД становятся уже совершенно безобразными, воткнуть очередь с денормализоваными хранилищами.

Подробно о всех преимуществах CQRS перед классической n-layer- и onion-архитектурой я рассказывал в докладе Быстрорастворимое проектирование.

Причем здесь Event Storming? Это техника специфицирования в терминах DDD, CQRS и Event Sourcing в форме увлекательной игры со стикерами, фломастерами и доской (доска может быть физической или виртуальной, но с физической гораздо веселее). С точки зрения наглядности, метод не успевает за Activity и BPMN-диаграммами. Но он гораздо более легковесный и прост в освоении и понимании.

Impact Mapping

И снова книга Гойко Аджича. Часть идей в ней пересекается со Specification by Example, но у книг разные целевые аудитории. Spec by Example лучше подойдет для разработчиков, архитекторов, тестировщиков, аналитиков и менеджеров среднего звена. Impact Mapping инструмент, в первую очередь, для бизнеса: владельцев продукта (или даже компании), маркетинга и топ-менеджмента. Spec by Example лишь поощряет общение с целью поиска оптимальных решений. Impact Mapping это формальный процесс для стратегического планирования. Его можно использовать не только в разработке ПО, но и для стратегического планирования, в целом. Например, в этом году мы использовали Impact Mapping для приоритизации и планирования задач в HR.

Теория + практика

Теоретически-практические книжки чуть более сложные. Я бы рекомендовал начать с DDD это очень холиварная тема! Возможно, DDD это не то, что вам нужно на этапе создания стартапа, но попробуйте обратить внимание не на технические аспекты, а на высокоуровневые паттерны. На то, как DDD предлагает общаться с экспертами, выделять главное, и на то, что продукт порой важнее используемых технологий. Если вам это зайдет, то дальше начнется протоптанная другими тропа: DDD -> CQRS -> Event Sourcing. Чаще всего все эти три темы обсуждаются в одном комьюнити. Как только вы разберетесь, что собой представляет каждая из концепций, вы поймете почему.

Немного особняком стоит книга Скотта Влашина про DDD в мире функционального программирования. Во-первых, ФП в изложении Влашина это не сложно. Обратите на книгу внимание хотя бы поэтому. Во-вторых, даже если в ближайшие десятилетия вы не собираетесь никуда сворачивать с тропинки объектно-ориентированного программирования, изучение других способов решения знакомых проблем может быть точкой роста. Я большой фанат гипотезы лингвистической относительности (и фильма Прибытие удачно выигрывающего эту гипотезу). В каком-то смысле знание языков программирования может влиять на ваше мировоззрение также, как знание естественных языков.

Теория

Факты и заблуждения профессионального программирования

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

Мифический человеко-месяц

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

Сколько стоит программный продукт

Большинство знает другую книгу МакКонела Совершенный код. Для кого-то она даже стала своеобразной Библией программирования. Если вы уже программируете хорошо и хотите научиться лучше оценивать трудозатраты на разработку, прочтите Software Estimation: Demystifying the Black Art (Сколько стоит программный продукт; в оригинале название звучит точнее, не находите?:). Книжка сложная, со статистикой, но ничего лучшего об оценке я не видел. Гарантирую, качество оценки тех, кто использует методы и советы из книги, многократно превосходит качество оценки тех, кто делает это по наитию.

Лютая теория и даже философия

Но если этого вам мало, и вы хотите улучшить свое умение думать о процессе, в целом, понять разницу между управлением, организацией и даже не прочь почитать что-то философское, то Г. П. Щедровицкий Оргуправленческое мышление это то, что вам нужно. Книга очень сложно читается, это конспект лекций для руководителей стройки атомных электростанций в СССР. На момент строительства никакой методологии Как строить атомные АС просто не существовало. Стройки велись по всему СССР, что делало каждый проект уникальным. В этих условиях успех строительства напрямую зависел от качества организации и от управления стройкой. В терминологии Щедровицкого эти два слова значат совсем не одно и тоже. В ходе лекций автор пытается найти баланс между первым и вторым. Труд просто фундаментальный и где-то философский, предназначенный для организаторов и руководителей с большой буквы.

Цель. Процесс непрерывного улучшения

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

На этом мой список книг подходит к концу. Выбирайте полезные для себя и enjoy!

TechLead Conf 2021 конференция, полностью посвященная инженерным процессам и практикам откроет свои двери уже совсем скоро: 30 июня и 1 июля она пройдет в Radisson Slavyanskaya (Москва).Расписаниеуже готово.Билетыв продаже. А ещё у нас открытдоступк докладам TechLead Conf 2020.

До встречи в офлайне!

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

В этом году уже три конференции (TeamLead Conf 2021, HighLoad++ Весна 2021 и DevOpsConf 2021) прошли в гибридном формате. Было интересно, полезно, необычно и продуктивно. Сегодня мы расскажем тем, кто еще не успел оценить нововведения лично, о том, в чем они состоят.

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

Что нового в онлайне?

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

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

На вкладке Выставка на платформе конференции участники могут пройтись по онлайн-стендам всех наших партнёров. Каталог участников может помочь найти единомышленников. Еще можно сформировать собственное расписание, добавляя в избранное интересные доклады. А в разделе Библиотека храним все презентации.

За лучшие вопросы, заданные в любом формате (офлайн или онлайн), мы дарим книги от наших партнеров. А потом пересылаем их в любую точку мира.

Что нового офлайн?

Главное достоинство офлайн-участия, которое вы так цените нетворкинг.

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

• Все сотрудники конференции сдают тест ПЦР и ходят в масках.

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

• Во всех помещениях конференции и в фойе работают мощные рециркуляторы воздуха.

• Между докладами предусмотрены перерывы 15 минут. Они заложены для того, чтобы обработать поверхности и проветрить.

• Каждый микрофон мы протираем спиртовыми салфетками, прежде чем передать его участнику.

• В зоне кофебрейков и обедов соблюдаются нормы социальной дистанции.

Следующие конференции пройдут уже совсем скоро. PHP Russia 2021 состоится 28 июня в московской Radisson Slavyanskaya. А 30 июня и 1 июля откроет свои двери TechLead Conf 2021 конференция, полностью посвященная инженерным процессам и практикам.

Мы будем рады видеть вас и в онлайне, и офлайн. Выбирайте свой формат участия, присматривайте классные доклады. И до встречи!

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

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

Почему мы чувствуем себя несчастными, работая с легаси-кодом?

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

Но с точки зрения старшего разработчика часто все выглядит так:

• приложение очень хрупкое: если фиксим где-то баг, в ответ прилетают два новых;

• есть regressions bugs они как вампиры, которых невозможно убить, каждый релиз появляются снова и снова;

• новые фичи занимают все больше времени: откладываются релизы, давят дедлайны, вы начинаете сознательно увеличивать время на планировании.

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

У меня есть одна история. Приходит менеджмент, говорит, что нам нужна эта фича, причем еще вчера. Мы работаем изо всех сил, релизим как можно быстрее. Затем говорим менеджменту: Теперь нам нужна неделя, чтобыотрефакторить, написать тесты. На что менеджер отвечает: Что? Выэтого несделали?.

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

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

Становилось всё хуже и хуже. Всё это привело к серьезному стрессу и потере мотивации. В конце концов, не дожидаясь, когда мы подойдём к моменту, что всё это станет не поддерживаемо, я ушел.

Есть другая крайность. Мы видим старую систему. Думаем: Если тот криворукий, кто написал этот ужас, смог заставить всё работать, тонаверняка это просто. Давайте перепишем всё уже по-нормальному. Сделаем красиво. Но это ловушка. Легаси-код уже пережил много деплоев и изменений требований. Начиная с начала, мы думать не думаем и знать не знаем о всех тех трудностях, которые пережил тот код. Да, мы пытаемся делать предположения, но зачастую они неверны. Почему так?

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

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

Шаг первый: пишем smoke-тесты, которые скажут, что приложение хотя бы живое

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

Что использовать? Нам понравился Codeception у него приятный интерфейс, можно быстро накидать smoke-тесты на наиболее критичные эндпоинты, сами тесты выходят лаконичными и понятными. А еще у него такой выразительный API и тест можно читать прямо как user story.

Что покрывать? Правило простое: покрываем тот функционал, который отвечает за бизнес-домен. В нашем случае это были тренировки слов мыпокрыли smoke-тестами его. Например, у нас был эндпоинт, который отдавал выученные пользователем значения слов.

/** * @see \WordsBundle\Controller\Api\GetLearnedMeanings\Controller::get() */final class MeaningIdsFromLearnedWordsWereReceivedCest{   private const URL_PATH = '/api/for-mobile/meanings/learned';    public function responseContainsOkCode(SmokeTester $I): void   {        }}

Мы явно прописали эндпоинт, который будем тестировать, и через аннотацию @see сделали указание на контроллер. Это удобно тем, что по клику в IDE можно сразу перейти в контроллер. И наоборот, по клику на экшен контроллера можно перейти в тест.

Сам тест был максимально прост: подготавливаем данные, сохраняем в базе выученное пользователем слово, авторизуемся под этим юзером, делаем get-запрос к API и проверяем, что получили 200.

public function responseContainsOkCode(SmokeTester $I): void{          $I->amBearerAuthenticated(Identity::USER);   $I->sendGET($I->getApiUrl(self::URL_PATH));   $I->seeResponseCodeIs(Response::HTTP_OK);}

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

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

public function responseContainsLearnedMeaningIds(SmokeTester $I): void{          $learnedWord = $I->have(       UserWord::class,        ['isKnown' => true, 'userId' => $I->getUserId(Identity::USER)]   );   $I->amBearerAuthenticated(Identity::USER);   $I->sendGET($I->getApiUrl(self::URL_PATH));   $I->seeResponseCodeIs(Response::HTTP_OK);    $I->seeResponseJsonMatchesJsonPath('$.meaningIds');    $I->seeResponseContainsJson(    ['meaningIds' => [$learnedWord->getMeaningId()]]    );

Так постепенно мы покрыли все критичные части нашего приложения и могли перейти непосредственно к коду.

Шаг второй: удаляем неиспользуемый код

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

Как понять, что удалять, а что нет. Довольно легко разобраться с каким-то доменным или инфраструктурным кодом. Совсем другое дело API и эндпоинты. Чтобы разобраться с ними, можно заглянуть в NewRelic и проекты на гитхабе. Но лучше прямо сходить к командам и поспрашивать может статься, что у вас есть какой-то эндпоинт, из которого аналитика раз в год выкачивает важные данные. И будет очень некрасиво удалить его, даже если по всем признакам его никто не вызывал уже почти год.

Шаг третий: делаем слой вывода

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

Например, у нас есть контроллер, который возвращает баланс пользователя. В этом примере мы просто достаём из репозитория сущность и как есть отдаём наружу то есть как только мы порефакторим, API у клиента поменяется.

final class Controller{   private Repository $repository;   public function __construct(Repository $repository)   {       $this->repository = $repository;   }    public function getBalance(int $userId): View   {       $balance = $this->repository->get($userId);       return View::create($balance);   }}

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

final class Balance{   public int $userId;   public string $amount;   public string $currency;   public function __construct(int $userId, string $amount, string $currency)   {       $this->userId = $userId;       $this->amount = $amount;       $this->currency = $currency;   }}

Всё, больше слой вывода никак не привязан к доменному коду, сам код стал более поддерживаемым.

final class Controller{   private Repository $repository;   public function __construct(Repository $repository)   {       $this->repository = $repository;   }    public function getBalance(int $userId): View   {       $balance = $this->repository->get($userId);       return View::create(Balance::fromEntity($balance));   }}

Можно спокойно начинать улучшать и рефакторить, не боясь сломать обратную совместимость API.

Шаг четвертый: статический анализ кода

В современном PHP есть strict types, но даже с ними можно по-прежнему менять значение переменной внутри самого метода или функции:

declare(strict_types=1); function find(int $id): Model{    $id = '' . $id;     /*     * This is perfectly allowed in PHP     * `$id` is a string now.     */     // } find('1'); // This would trigger a TypeError. find(1); // This would be fine.

А так как типы проверяются в runtime, проверки могут зафейлится во время выполнения программы. Да, всегда лучше упасть, чем словить проблем из-за того, что строка внезапно превратилась в число (причем не то число, которое мы бы ожидали увидеть). Но иногда хочется просто не падать в runtime. Мы можем выполнить проверки до выполнения кода с помощью дополнительных инструментов: Psalm, PHPstan, Phan и так далее.

Мы в проекте выбрали Psalm. Возможно, у вас возник вопрос: зачем тащить в легаси-проект статический анализ, если мы и без него знаем, что код там не очень? Он поможет проверить неочевидные вещи. В легаси-проектах часто встречается так называемый array-driven development структуры данных представлены массивами. Например, есть легаси-сервис, который регистрирует пользователей. Он принимает массив $params.

final class UserService{   public function register(array $params): void   {       // ...   }}$this->registration->register($params);

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

final class UserService{   /**    * @psalm-param array{name:string, surname:string, email:string, age:integer} $params    */   public function register(array $params): void   {       // ...   }}$this->registration->register($params);

Прописав через докблоки формат и тип данных, при следующем рефакторинге мы запустим Psalm, он проверит все возможные вызовы и заранее скажет, сломает ли код. Достаточно удобно при работе с легаси.

Что дальше?

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

А дальше просто подумайте, что еще нужно, чтобы чувствовать себя счастливым, работая с этим кодом. Чего еще не хватает? Составьте себе план действий и постепенно улучшайте доставшийся вам в наследство код.

p.s. Несколько полезных материалов для дальнейшего изучения:

• Пост основан на докладе с краснодарского PHP-митапа вот его запись

• Больше о статическом анализе и Psalm

• Интересная история про переписывание проекта на PHP

• Что дальше делать с тестами

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

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

ClickHouse для тестов железа

Самое простое, что можно сделать с ClickHouse, если есть свободные серверы это использовать его для тестов оборудования. Потому что его тестовый dataset содержит те же данные с production Яндекса, только анонимизированные и они доступны снаружи для тестирования. Про то, как подготовить хорошие анонимизированные данные, я рассказывал на Saint HighLoad++ 2019 в Санкт-Петербурге.

Ставим ClickHouse на любой Linux (x86_64, AArch64) или Mac OS. Как это сделать? мы собираем его на каждый коммит и pull request. ClickHouse Build Check покажет нам все детали всех возможных билдов:

Отсюда можно скачать любой бинарник с gcc и clang в релизе, в debug, со всякими санитайзерами или без, для x86, ARM или даже Mac OS. ClickHouse использует все ресурсы железа: все ядра CPU, шины памяти и грузит все диски. Какой сервер ему не дай проверит полностью, хорошо или плохо тот работает.

По этой инструкции можно скачать бинарник, тестовые данные и запустить запросы. Тест займёт около 30 минут и не требует установки ClickHouse. И даже если на сервере уже установлен другой ClickHouse, вы все равно сможете запустить тест.

В результате мы получаем публичный список протестированного железа:

Все результаты мы получаем от пользователей через краудсорсинг и выглядят они примерно так:

Вы можете выбрать серверы для сравнения для каждого можно посмотреть разницу в производительности. Конечно, и других тестов железа существует немало, например, SPECint и вообще куча тестов из организации SPEC. Но ClickHouse позволяет не просто тестировать железо, а тестировать рабочую СУБД на настоящих данных на реальных серверах откуда угодно.

ClickHouse без сервера

Конечно, обычно ClickHouse это сервер + клиент. Но иногда нужно просто обработать какие-то текстовые данные. Для примера я взял все исходники ClickHouse, собрал их в файл и сконкатенировал в файл под названием code.txt:

И, например, я хочу проверить, какие строчки в коде на C++ самые популярные. С помощью типичной shell-команды удалим из каждой строчки кода начальные пробелы и пустые строки, отсортируем и посчитаем количество уникальных. После сортировки видим, что, конечно, самая популярная строчка это открывающая фигурная скобка, за ней закрывающая фигурная скобка, а еще очень популярно return false.

Этот результат я получил за 1,665 секунд. Потому что все это было сделано с учетом сложной локали. Если локаль заменить на простую, выставив переменную окружения LC_ALL=C, то будет всего лишь 0,376 с, то есть в 5 раз быстрее. Но это всего-лишь шел скрипт.

Можно ли быстрее? Да, если использовать clickhouse-local, будет еще лучше.

Это как-будто одновременно и сервер и клиент, но на самом деле ни то, и ни другое clickhouse-local может выполнять SQL запросы по локальным файлам. Вам достаточно указать запрос, структуру и формат данных (можно выбрать любой из форматов, по умолчанию TabSeparated), чтобы обработать запрос на входном файле. За 0.103 секунд то есть в 3,716 раз быстрее (в зависимости от того, как вы запускали предыдущую команду).

Для демонстрации чего-то более серьезного давайте посмотрим на те данные, которые собирает GitHub Archive это логи всех действий всех пользователей, которые происходили на GitHub, то есть коммиты, создание и закрытие issue, комментарии, код-ревью. Все это сохраняется и доступно для скачивания на сайте https://www.gharchive.org/ (всего около 890 Гб):

Чтобы их как-нибудь обработать, выполним запрос с помощью ClickHouse local:

Я выбрал все данные из табличной функции file, которая берет файлы вида *.json.gz то есть все файлы в формате TSV, интерпретируя их как одно поля типа string. С помощью функции для обработки JSON я вытащил из каждой JSONины сначала поле 'actor', а потом поле 'login' в случае, когда оно равно Алексей Миловидов и выбрал таких первых 10 действий на GitHub.

Может возникнуть впечатление, что 890 Гб данных смогли обработаться за 1,3 секунды. Но на самом деле запрос работает потоково. После того, как находятся первые 10 строк, процесс останавливается. Теперь попробуем выполнить более сложный запрос, например, я хочу посчитать, сколько всего действий я совершил на GitHub. Используем SELECT COUNT... и через полторы секунды кажется, что ничего не происходит. Но что происходит на самом деле, мы можем посмотреть в соседнем терминале с помощью программы dstat:

И мы видим, что данные читаются с дисков со скоростью примерно 530 Мб/с и все файлы обрабатываются параллельно почти с максимальной скоростью насколько позволяет железо (на сервере RAID из нескольких HDD).

Но можно использовать ClickHouse local даже без скачивания этих 980 Гб. В ClickHouse есть табличная функция url то есть можно вместо file написать адрес https://.../*.json.gz, и это тоже будет обрабатываться.

Чтобы можно было выполнять такие запросы в ClickHouse, мы реализовали несколько вещей:

1. Табличная функция file.

2. Поддержка glob patterns. В качестве имени файлов можно использовать шаблон с glob patterns (звёздочка, фигурные скобки и пр.)

3. Поддержка сжатых файлов в формате gzip, xz и zstd из коробки. Указываем gz и всё работает.

4. Функции для работы с JSON. Могу утверждать, что это самые эффективные функции для обработки JSON, которые мы смогли найти. Если вы найдёте что-нибудь лучше, скажите мне.

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

6. Тот самый параллельный парсинг.

Применять можно, само собой, для обработки текстовых файлов. Еще для подготовки временной таблицы и партиций для MergeTree. Можно провести препроцессинг данных перед вставкой: читаете в одной структуре, преобразовываете с помощью SELECT и отдаете дальше в clickhouse-client. Для преобразования форматов тоже можно например, преобразовать данные в формате protobuf с разделителями в виде длины в JSON на каждой строке:

clickhouse-local --input-format Protobuf --format-schema такая-то --output format JSONEachRow ...

Serverless ClickHouse

ClickHouse может работать в serverless-окружении. Есть пример, когда ClickHouse засунули в Лямбда-функцию в Google Cloud Run: https://mybranch.dev/posts/clickhouse-on-cloud-run/ (Alex Reid). Там на каждый запрос запускается маленький ClickHouse на фиксированных данных и эти данные обрабатывает.

Текстовые форматы

Для обработки текстовых данных, естественно, есть поддержка форматов tab separated (TSV) и comma separated (CSV). Но еще есть формат CustomSeparated, с помощью которого можно изобразить и тот, и другой в качестве частных случаев.

CustomSeparated:

format_custom_escaping_rule

format_custom_field_delimiter

format_custom_row_before/between/after_delimiter

format_custom_result_before/after_delimiter

Есть куча настроек, которые его кастомизируют. Первая настройка это правило экранирования. Например, вы можете сделать формат CSV, но в котором строки экранированы как в JSON, а не как CSV. Разница тонкая, но довольно важная. Можно указать произвольный разделитель типа | и пр. между значениями, между строками и т.п.

Более мощный формат это формат Template:

format_template_resultset

format_template_row

format_template_rows_between_delimiter

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

Есть формат Regexp:

format_regexp

format_regexp_escaping_rule

format_regexp_skip_unmatched

И тут clickhouse-local превращается в настоящий awk. Указываете регулярные выражения, в Regexp есть subpatterns, и каждый subpattern теперь парсится как столбец. Его содержимое обрабатывается согласно некоторому правилу экранирования. И конечно можно написать пропускать строки, для которых регулярное выражение сработало, или нет.

ClickHouse для полуструктурированных данных

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

Допустим, у вас есть таблица с логами, в ней есть столбец с датой и временем, а вот всё остальное вообще непонятно что. Очень соблазнительно всю эту кучу данных записать в один столбец 'message' с типом String. Если эта куча в формате JSON, функции для работы с JSON будут работать. Но неэффективно каждый раз, когда нам будет нужно только одно поле, например 'actor.login', читать придется весь JSON не будет преимущества столбцовой базы данных. С помощью ClickHouse мы легко это исправим прямо на лету, добавив с помощью запроса ALTER материализованный столбец:

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

ALTER TABLE logs UPDATE actor_login = actor_login

И вы можете добавлять столбцы по мере необходимости, чтобы ускорить запросы.

Ускорение MySQL

В ClickHouse можно создать таблицу на основе табличной функции MySQL. Это просто: указываете хост: порт, БД, таблицу, имя пользователя и пароль (прямо так, как есть), делаем SELECT и всё выполняется за 15 секунд:

Работает это тоже без всякой магии: табличная функция MySQL переписывает запрос, отправляет его в MySQL и читает все данные назад, на лету на всё 15 секунд. Но что будет, если я тот же самый запрос выполню в MySQL как есть?

5 минут 41 секунда это позор! У ClickHouse тут как-будто нет преимуществ данные нужно переслать из MySQL в ClickHouse и потом уже обработать. А MySQL обрабатывает сам у себя локально почему же он так медленно работает?

Еще одна проблема результаты расходятся. У ClickHouse две строки счетчик (20577 и 13772), у MySQL один (44744), потому что он здесь учитывает collation (правила сравнения строк в разном регистре) при GROUP BY. Чтобы это исправить, можно перевести имя в нижний регистр, сгруппировать по нему и выбрать любой вариант:

Теперь счетчик один, данные почти совпадают и запрос даже ускорился. То есть ClickHouse быстрый независимо от того, какие выражения я напишу. Попробуем ускорить запрос еще больше. На основе данных из MySQL в ClickHouse можно создать словарь. Указываем в словаре ключ и источник MySQL со всеми этими данными:

Словарь будет периодически загружать таблицу в оперативку, она будет кэшироваться. Можно применять SELECT:

Получилось уже 6 секунд, хотя основное предназначение словаря использование для джойнов, когда, например, нам нужно получить данные динамически через другие столбцы. Можно также создать словари MySQL на каждом сервере в кластере ClickHouse и быстро с ними работать. Но если MySQL не выдержит нагрузки при обновлении словаря на каждом сервере в кластере, то можно создать из MySQL словарь на двух ClickHouse-серверах, и они будут доступны в виде таблиц в ClickHouse. Если с помощью движка Distributed создать таблицу, которая смотрит на эти два сервера как на реплики, то можно на всех ClickHouse-серверах создать словари из ClickHouse, которые смотрят на таблицу, которая смотрит на словарь MySQL.

Словари еще можно использовать для шардирования, если схема расположена во внешней мета-базе (и не обязательно в ClickHouse). Это тоже будет работать:

Есть вариант как радикально ускорить запрос, и для этого не нужны словари надо всего лишь переложить данные в полноценную таблицу типа MergeTree такой же структуры. Вставляем туда данные и делаем SELECT:

Видим, что SELECT выполняется за 0,6 с. Вот это настоящая скорость, какая должна быть это скорость ClickHouse!

В ClickHouse можно даже создать базу данных типа MySQL. Движок БД MySQL создает в ClickHouse базу данных, которая содержит таблицы, каждая из которых представляет таблицу, расположенную в MySQL. И все таблицы будут видны прямо в ClickHouse:

А вообще в ClickHouse много табличных функций. Например, с помощью табличной функции odbc можно обратиться к PostgreSQL, а с помощью url к любым данным на REST-сервере. И все это можно поджойнить:

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

Машинное обучение в ClickHouse

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

Это можно использовать для заполнения пропусков в данных. Пример: компания, занимающаяся недвижимостью, публикует объявления о квартирах с разными параметрами: количество комнат, цена, метраж. Часто некоторые параметры не заполнены например, квадратные метры есть, а количества комнат нет. В этом случае мы можем использовать ClickHouse с моделью CatBoost, чтобы заполнить пропуски в данных.

Более простые модели можно обучать прямо в ClickHouse. Модель машинного обучения у нас будет представлена как агрегатная функция например, стохастическая логистическая регрессия. Задаются гиперпараметры, значение предсказываемой функции и значения фич, причем обучение будет независимым для каждого ключа агрегации, если в запросе указан GROUP BY:

А еще мы можем добавить к агрегатной функции суффикс State:

SELECT stochasticLogisticRegressionState(...

Так можно обучить логистическую регрессию для каждого k и получить состояние агрегатной функции. Состояние имеет полноценный тип данных AggregateFunction(stochasticLogisticRegression(01, 00, 10, 'Adam'), ...), который можно сохранить в таблицу. Достать его из таблицы и применить обученную модель можно функцией applyMLModel:

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

Более развернуто описано в этой презентации.

ClickHouse как графовая база данных

Конечно, ClickHouse это не графовая БД и никогда даже не планировался для этого, но тем не менее. Представьте, что таблицы представляют собой ребра графа. С помощью табличной функции можно записывать алгоритмы на графах, например, реализовать алгоритм pagerank:

Это работает, и говорят, даже быстрее, чем некоторые другие графовые базы данных. Разработал его наш друг, один из ведущих контрибьюторов Amos Bird. Правда, эта разработка не доступна в open-source. Но мы не обижаемся.

UDF в ClickHouse

Казалось бы, в ClickHouse нет возможности написать пользовательские функции (user defined functions). Но на самом деле есть. Например, у вас есть cache-словарь с источником executable, который для загрузки выполняет произвольную программу или скрипт на сервере. И в эту программу в stdin передаются ключи, а из stdout в том же порядке мы будем считывать значения для словаря. Словарь может иметь кэширующий способ размещения в памяти, когда уже вычисленные значения будут кэшированы.

И если вы пишете произвольный скрипт на Python, который вычисляет, что угодно пусть те же модели машинного обучения, и подключаете его в ClickHouse, то получаете вы как раз аналог user defined function.

Примечание: полноценная реализация UDF находится в roadmap на 2021 год.

ClickHouse на GPU и как Application Server

Это ещё два необычных примера. В компании nVidia ClickHouse заставили работать на графических ускорителях, но рассказывать я про это не буду.

А наш друг Zhang2014 превратил ClickHouse почти в Application Server. У Zhang2014 есть pull request, где можно определить свои HTTP-хэндлеры и этим хэндлерам приписать подготовленный запрос (SELECT с подстановками или INSERT). Вы делаете POST на какой-то хэндлер для вставки данных, или делаете вызов какой-то GET ручки, передаете параметры, и готовый SELECT выполнится.

Вывод

ClickHouse очень интересная система, в которой всегда можно найти что-то новое, причем, что интересно, что-то новое там всегда могу найти даже я. Многие разработчики удивляют меня тем, что они могут реализовывать внутри ClickHouse всего лишь чуть-чуть поменяв его код. И эти штуки будут работать и в production!