Всем привет, меня зовут Влад, и я в IT около семи лет. Ранее я писал статьи о том, как изучать .NET, и о том, как найти первую работу. В этой статье речь пойдет о моем видении, что такое собеседование, как оно устроено и какие ошибки не стоит совершать кандидатам и интервьюерам.

В чем суть собеседования

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

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

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

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

В целом для оценки навыков человека используется условное их разделение на hard & soft skills.

Hard skills

Одна из плоскостей знаний и навыков, которые проверяют на собеседовании, — hard skills, то есть технические навыки.

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

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

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

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

Что спрашивают

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

• Теоретические знания, копание в основах — это может быть заполнение тестов, личные расспросы по нюансам языка/технологии, некоторые энциклопедические знания. Показывают базовую подготовку человека, достаточно универсальный подход, чтобы дать или не дать человеку абстрактные баллы. Однако из минусов — если человек, например, на работе последнее время ковырял только базу данных, то другие вещи, типа фронтенда, могли просто вылететь из головы, даже если когда-то он их знал хорошо. Обычно этот пункт очень любят на интервью с начинающими разработчиками, ведь большого опыта у них нет, но хорошее знание основ — это то, что может выделить потенциально более перспективного кандидата.
• Вопросы по паттернам и лучшим практикам — показывают, насколько человек в курсе лучших решений типичных проблем и как он применял эти решения в своей практике.
• Умение строить логические абстракции — предложение построить диаграмму классов, спроектировать структуру несложной базы данных с последующим написанием к ней запросов, разделить систему на уровни или модули и так далее.
• Практический опыт — вещи, которые нельзя понять в теории или заучить. Например, нарисуй архитектуру для конкретного случая, найди компромисс в поставленной задаче и ответь на каверзный вопрос, не имеющий однозначного ответа.
• Решение прикладных задач. Например, как передать значения из потока в поток, какие значения будут иметь переменные в определенный момент. Может быть также в формате — написать на листочке кусок кода. Основная задача — выяснить, насколько человек ориентируется в фичах конкретного стека.
• Умение быстро мыслить, пользоваться интернетом. Возможно, что на собеседовании вам дадут возможность использовать поисковики для решения небольшого тестового задания. Этот способ имеет под собой цель проверить, как вы будете действовать в условиях нехватки информации, насколько способны докапываться до решения проблемы, используя форумы и статьи. Для разработчиков middle+ уровня — очень важный навык.
• Умение выяснять требования — вам дают задачу, не до конца понятную, либо же специально имеющую неоднозначную трактовку, требования. Смотрят, насколько быстро вы найдете противоречия в постановке задачи либо же неполноту информации.
• Алгоритмические задачи — их очень любят в компаниях типа Google или Microsoft. Считается, что хорошее знание алгоритмов и умение их применять делает инженера хорошим специалистом, способным освоить что угодно и реализовать что угодно. Но решать алгоритмические задачи без подготовки довольно сложно, если вы не обладаете школьной/университетской олимпиадной базой. Поэтому если есть вероятность, что на интервью вам придется решать такие задачи — подготовьтесь заранее.
• Треш-головоломки — часто карго-культ на собеседованиях в местные стартапы. Человека спрашивают, «сколько молотков нужно, чтобы выгнать медведя из берлоги», и ждут некоего ответа. Возможно, проверяется острота мышления или еще что-то, известное только интервьюерам.
• Выяснение предыдущего опыта и роли на проектах — у человека детально спрашивают, какие задачи он решал в рамках прошлых проектов, какие решения принимал и почему. Это позволяет сложить общую картину о человеке как о специалисте и о том, что он гарантированно умеет.
• Тестовое задание домой — если есть сомнения либо просто хочется убедиться в опыте кандидата и уместности его подхода к работе — можно дать тестовое задание, где кандидат покажет «his best». Еще один из факторов — проверка на серьезность намерений. Если человек готов выполнить тестовое задание, то, скорее всего, в случае оффера он его примет с бОльшей вероятностью.

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

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

Soft skills

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

Конструктивное обсуждение вопроса отличается от неконструктивного тем, решается ли в процессе обсуждения проблема или нет.

Я выделил такие важные нетехнические навыки:

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

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

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

Что спрашивают

Я составил такой список того, на что могут смотреть менеджеры по персоналу:

• Узнать увлечения кандидата — есть ли что-то, что объединяет его с уже сложившимся коллективом, интересен ли вообще человек как человек.
• Замкнутость человека — насколько с ним легко начать беседу, насколько человек способен вовлекать в беседу либо вовлекаться. Если это, к примеру, команда поддержки/системных интеграторов продукта, которые постоянно ведут общение, то будет странным решением поставить туда человека, не желающего делиться знаниями и не склонного просить помощи у других.
• Энергичность — человеческая психика устроена таким образом, что если человек реально не хочет чего-то, у него и не будет сил для этого. Следовательно, мотивированный кандидат не будет бояться, стесняться или мямлить. Если есть цель попасть в компанию, человек будет к ней двигаться. А какой смысл брать людей, не умеющих следовать к своим целям или тех, кто не имеет их вовсе?
• Рассказ о самом крутом или сложном проекте — насколько человеку вообще интересна работа и насколько он ею увлечен. Идеальный работник — это тот, которому чем сложнее, тем интереснее. Это имеет смысл и для работника: если вы научились кайфовать от вызовов и решения сложных задач, то вам же лучше.
• Выяснение лояльности к компании — насколько человек потенциально будет вкладываться в развитие компании, насколько для него важно быть ее частью. Сюда же можно отнести вопросы про планы на пять лет, переход на +$300 и почему человек хочет работать в этой компании. Некоторые компании даже могут поставить вам черную метку, если в разговоре вы скажете, что не слышали о них или ничего не знаете. Зачем вам это нужно? В этом случае элементарно закрывается риск потери человека при стечении обстоятельств, но лично я думаю, что такие вопросы реально мало что дадут и в них часто есть перегибы.
• Просто приятный человек — насколько субъективно приятно общаться с человеком. Если ты суперспециалист в грязной одежде и с неприятным запахом — ты будешь вызывать отторжение.
• Насколько человек профессионально выгорел. Способен ли будет человек активно обучаться и вовлекаться в работу новой команды. Уставший сотрудник физически не сможет стартовать на высоких оборотах.
• Тесты на IQ — субъективные метрики, в которые верит менеджмент, которые могут сказать что-то в пользу или против человека. С таким же успехом можно гадать на картах либо по гороскопу, но видимо это может работать, если это используют где-то.

И наконец-то — выяснение ожиданий по ЗП. Та метрика, по которой идет дальнейшее сравнение кандидатов в пуле в соотношении стоимость/качество. Тут есть нюанс: компании разного типа готовы платить за вас разные деньги. Это вытекает из природы их бизнеса. Однако есть рынок, и намного выше рынковой ЗП тоже не прыгнет.

Если это стартап (компания в процессе поиска бизнес модели, без значительных инвестиций и штата) — денег там очень мало, стараются завлекать интересом/свободой/развитием, знайте что вкалывать там придется порядочно.

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

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

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

Жизненная история, или Как не стоит проводить собеседование

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

Утро понедельника было тяжелым. Тимлид Саша и сеньор Паша, отходившие от корпоратива в воскресенье, еще были на сушняке. Но вспомнив, что через час-полтора к ним придет кандидат — зашевелились и начали думать, что же все-таки у него спросить. Не долго думая, Паша загуглил «<название технологии> вопросы на собеседования». Саша был более продвинутым чуваком, а посему искал «top ten interview question for <название технологии>». Выписав трясущейся рукой 10-20вопросов на листочек с эмблемой лидеров рынка, они отправились в переговорную. Новая HR Таня, за заигрывание с которой вчера обоим было стыдно, завела кандидата, который, нервно покусывая ручку, сидел и ждал своего часа.

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

• Что лучше — абстрактный класс или интерфейс?
• Что такое инкапсуляция, наследование, полиморфизм?
• MVC/MVP/MVVM?

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

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

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

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

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

Первым делом директор пытался выяснить, насколько кандидат осведомлен о рынке зарплат. Спрашивал: «И на что ты столько денег тратить будешь? У тебя что, жена есть и дети? Ты же понимаешь, что это очень много?».

Кандидат, пожав плечами, ответил: «Ну, я на DOU читал».

• Врут все на DOU, — однозначно ответил Валентин Петрович. — Да, Танюша?
• Да-да, Валентин Петрович, — кивнула Таня, чуть не выронив какие-то бумаги.
• Но мы в лидерах рынка, и наша компания может позволить такую зарплату тебе платить. Но ты же понимаешь, какое доверие тебе оказано? О том, что ты будешь получать больше всех в отделе, ты не должен никому рассказывать. Это будет наш маленький секретик.
• И ты должен вкладываться в работу соответствующе, — продолжал Валентин Петрович. — Согласна, Танюш?
• Да-да, Валентин Петрович, — на автомате кивнула Таня.

После десяти минут вакханалии и восхваления компании Петрович таки отпустил кандидата восвояси, а Танюшу попросил остаться.

Последнее, что услышал кандидат, было: «Мы вам обязательно перезвоним! До связи».

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

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

Как все же кандидату готовиться к интервью

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

Но если времени совсем малои не хочется провалиться из-за того, что элементарные вещи вылетели у вас из головы — поищите в гугле: «вопросы на собеседования/интервью по <название вашей технологии>».

Если времени хватает, узнайте побольше о компании, куда хотите устроиться: какой технологический стек там используется, пообщайтесь с людьми оттуда, как они проходили интервью, на что делался больший акцент. Никто не запрещает вам прийти в гости в компанию через HR’ов и пообщаться с техническими специалистами (скорее всего, вам дадут лида если у него будет время). В свободной форме вы можете узнать, на чем делается акцент в интервью, какие навыки считаются более ценными и на что обратить внимание в самообразовании. Вы можете прямо сказать HR’ам, что ваша цель — выяснить, как попасть в их компанию, и это подход win/win для всех. Вы показываете себя проактивным кандидатом, а по логике: какой вы кандидат — такой и работник. Компания может получить специалиста с уже востребованным набором навыков. Но это более уместно для продуктовых компаний, имеющих заточку под какой-то конкретный стек технологий.

Этот подход работает как для сеньоров, так и для начинающих специалистов. Вопрос лишь в степени погружения.

Что поможет получить оффер

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

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

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

• Демонстрация своих технических навыков — кроме общения на интервью, очень важную роль может то, что вы покажете ваши наработки на GitHub. GitHub не врет кто есть кто :)
• Наличие своих реально работающих проектов — запуск, к примеру, какого-то онлайн-сервиса в условиях нехватки времени — требует огромной проактивности, мотивации и интереса к разработке.
• Публичная активность — выступления на конференциях, написание книг или статей — показывает ваше умение подавать людям материал, не бояться быть на виду, хорошее знание какой-то области и что немаловажно — что вам это интересно. А если вам интересно, то вы будете готовы преодолевать любые сложности.
• Отзывы с предыдущих мест работы,например через LinkedIn. Если о вас пишут положительные отзывы, то велика вероятность все же, что вас там не ненавидели, и с вами действительно было удобно и приятно работать.
• Белая история в соцмедиа — если поискав вашу фамилию и имя в интернете, HR’ы обнаружат вас в странных историях, или на своей странице в FB вы будете проявлять нетолерантность по разным спорным вопросам, это повод выбрать не вас.

На этом все. Удачи всем, и, если у вас остались вопрос или пожелания — пишите мне на FB Vladislav Furdak.

В рубрике DOU Labsмы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

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

Solution.Мы разработали бота на основе Microsoft Bot Framework, который ежедневно в 11:00 проверяет, что time report внесен в систему учета. В противном случае он уведомляет сотрудника об этом личным сообщением в корпоративный Slack. О разработке бота и расскажем в статье.

Реализация

Ukad slack-бот построен на Microsoft Bot Framework. Этот фреймворк подходит для различных платформ, не требуя отдельной реализации функционала для каждой. Microsoft Bot Frameworks соединяет все подходы, позволяя разработчику с помощью одного бота контролировать разные платформы, подключив Facebook, Skype, Slack и так далее. Всем этим способен управлять только один инстанс бота, и это одна из главных задач. Помимо канала, который поддерживает Microsoft Bot Frameworks мы можем реализовать свои собственные, создавая поддержку любого канала в рамках MBF или подключив бот на сайте.

Ukad slack-бот реализует Slack API. Мы помогаем сотрудникам отслеживать рабочие часы, напоминая вводить данные о времени в тайм-трекер, если он не заполнен. Сейчас мы также подключили оповещения о графике отпусков и оповещения для админов. Теперь тимлиды могут планировать проекты, учитывая информацию об отсутствии/присутствии в офисе нужных сотрудников, а админы вовремя реагировать на новые таски.

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

Как это работает

У бота есть 2 режима.

1. User initiated dialog.

Из набора слов, которые пользователь пишет боту, используя NLP (natural language processing), бот вычленяет намерение, intent. Например, вопрос о погоде. Бот должен распознать «weather» как intent, «сегодня» — как сегодняшнее число.

Бот понимает, чего хочет пользователь, запускает нужный диалог и может валидировать данные. Например, мы хотим получить от пользователя уточнение в виде текста (например, погода в каком городе) или дать пользователю возможность ответить на список вопросов (диалог может представлять собой form fill или quiz).

2. Bot initiated dialog.

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

Что под капотом

MS Bot Framework имеет 2 реализации: С# и Node.js. В данном кейсе был выбран Node.js из-за его гибкости. Диалоги внутри бота — это готовые функции. Если вы хотите менять саму топологию диалогов и архитектуру бота в C#, вам потребуется использовать reflection. В Node.js это делается гораздо проще. Крайне выгодной получается архитектура «1 бот — много сценариев», когда мы конструируем какой-то универсальный бот и при старте из API задаем его структуру.

Бот должен быть подключен к каналу взаимодействия с пользователем (FB, Slack, Skype, Web application и т. д.). Для этого в MS Bot Framework есть интерфейс IConnector. Мы могли бы воспользоваться реализацией Microsoft и подключить Azure Connector, который может агрегировать сообщения от всех подключенных каналов и присылать на API вашего бота. Но мы пошли путем самурая и реализовали свой Slack Сonnector. Это нам дало больше функций, чем у реализации Slack API от MS. Также Azure Connector не бесплатный и тарифицируется по количеству сообщений, а наш бот — нет.

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

Классическая схема — когда у нас есть API в интернете, куда нам присылают сообщения, а по другому адресу мы уже отправляем ответы. В Azure есть специальный контейнер для Bot Framework, где мы можем разместить приложение и получить endpoint, однако можно сделать то же самое у себя на сервере. Наша реализация состоит из Slack RTM client. Это сокет, по которому мы получаем сообщения, а отправляем их через Slack Web API.

После этого нужно определиться, хранить ли состояние диалогов и, если да, то как долго. Диалоги можно хранить в памяти, а можно в БД. Есть стандартные реализации для Cosmos DB и оперативной памяти. Однако лучше всего написать свою реализацию интерфейса IBotStorage для вашей любимой БД (существует всего три метода). Мы сделали под NoSQL.

Дальше остается только наполнять приложение логикой, для чего Bot Framework предоставляет огромное количество инструментов. Мы создали API, через который наши внутренние сервисы рассылают уведомления сотрудникам. Реализуется Bot initiated dialog сценарий, который описан выше. Также созданы intent диалоги, которые реализуют User initiated dialog сценарий и вызываются в зависимости от ввода пользователя.

Основной Stack технологий: Node.js, MS Bot Framework, Typescript, NeDB, Slack SDK, DialogFlow.

Вывод

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

Тем, кто часто использует ReSharper, знакомо предупреждение «Possible NullReferenceException» — так код проверяется еще до выполнения. Особенно хорошо, что не нами. Анализировать таким образом можно любую сложную систему, организованную по определенным правилам. Сегодня я расскажу, как это работает для префабов в Unity.

Предыстория

Композиция требует начать со вступления. Так и поступим. Некоторое время назад мы командой около десяти человек переносили Flash-игру на WebGL. Игре было много лет, написана другим языком (ActionScript 3), а целевая платформа WebGL едва вышла из стадии эксперимента. Времени нам хватало ровно для того, чтобы постоянно чувствовать его нехватку.

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

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

В пылу разработки каждый день всплывали новые факты о том, что и как работает. На основании этих фактов появлялись правила, приемы и рекомендации: не использовать компонент Shadow, потому что он медленный (и есть аналоги эффективнее); делать объекты неактивными и дописывать им окончание «_h», если активность управляется извне; убирать флажок Raycast Target у картинок (компонент Image), если они не взаимодействуют с мышью и т. д. Тут были как безобидные детали общего стиля, так и штуки, которые могут уничтожить приложение.

Однажды я узнал, что в окне иерархии сцены в Unity можно рисовать прямо на объектах. И меня вдруг осенило. В сущности, так-то и не совсем вдруг, но однажды я подумал вот что: раз мы часть ресурсов отводим на поиск ошибок, то, может, пусть нечего будет искать? Например, добавит кто-то Shadow на объект, и тотчас появится иконка с предупреждением, мол, осторожнее, возможно, ты не хотел этого делать, и вот почему...

Идея и наброски

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

Итак, требуется проверять объекты и рисовать иконки, если что не так. Ограничимся пока простым интерфейсом:

public interface IAnalyzer
{
    bool Execute(GameObject gameObject);
}

Уже можно проверять использование компонента Shadow:

public sealed class ContainsShadowAnalyzer : IAnalyzer
{
    public bool Execute(GameObject gameObject) =>
        gameObject.GetComponent<Shadow>() != null;
}

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

Следующий вопрос: когда анализировать? Раз уж мы согласились, что рисовать на объектах в окне иерархии можно, оттуда и начнем. А именно — с события EditorApplication.hierarchyWindowItemOnGUI.

Получается так:

private static void OnItemGUI(int instanceID, Rect rect)
{
    if (!_isEnabled)
        return;

    var instance = EditorUtility.InstanceIDToObject(instanceID) as GameObject;
    if (instance == null)
        return;

    // Analyzers собираем через рефлексию куда-нибудь в поле.
    if (!Analyzers.Any(x => x.Execute(instance)))
        return;

    DrawWarningTriangle(rect);
}

private static void DrawWarningTriangle(Rect rect)
{
    var texture = Resources.Load<Texture>("Editor/warning"); // Путь к иконке.
    var aspect = (float) texture.width / texture.height;

    rect.y += 1;
    rect.height = rect.height - 2;

    var width = rect.height * aspect;
    rect.x += rect.width - width - 4;
    rect.width = width;

    GUI.DrawTexture(rect, texture, ScaleMode.StretchToFill, true, aspect);
}

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

Архитектура

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

Оценки

В первую очередь отметим, что результат работы анализатора (IAnalyzer выше) выражается только в «да» или «нет» (bool). Слишком поверхностно. Нужно нарастить семантику. В ООП (и не только) мы делаем это с помощью новых понятий, и, раз уж заговорили про оценки, можно так и написать —Diagnostic:

public interface IDiagnostic
{
    DiagnosticSeverity { get; } // Error, Warning, Hint.
    DiagnosticId { get; } // Уникальный идентификатор проверки.
    
    void Draw(Rect rect); // Rect будет попадать сюда из метода `OnItemGUI` (см. выше).
}

Предвижу замечание: что метод Drawделает в модели? Хороший вопрос. Хотя тут вообще прямая зависимость от Rect (View), что еще хуже. Но это как раз тот случай, когда ты знаешь, что никто не захочет всё это дело потом переиспользовать в каких-то консольных или WPF-проектах. А если и захочет, то изменить существующее проще (изменения вполне определенные и независящие от масштабов системы), чем закладывать избыточную сложность. Это если одним предложением. Еще проще: система анализа — проста, и усложнять ее заранееизбыточно.

Интерфейс анализатора также подстраивается:

public interface IAnalyzer
{
    DiagnosticId DiagnosticId { get; }
    // Обобщили GameObject до общего Object, чтобы подставлять еще Component.
    IDiagnostic Execute(UnityEngine.Object context);
}

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

Скорость

Итак, если анализаторов будет много (а это ожидается), то как их запускать сразу на всех объектах и чтобы быстро? Выше я писал о том, что EditorApplication.hierarchyWindowItemOnGUIотрабатывает слишком часто. Незачем многократно перепроверять объекты, когда кликаешь по сцене или ходишь по дереву, — ничего ведь не изменилось. Нужно еще какое-нибудь событие.

Например, EditorApplication.hierarchyWindowChangedоповещает об изменении элементов окна иерархии (добавляется/удаляется объект/компонент). Теперь можно провернуть такое: будем проверять объекты всё так же в момент отрисовки, но делать это будем не напрямую, а через некую AnalysisSession. Там инкапсулируем все существующие анализаторы и кэш.

Сценарий получится следующим:

• я анализирую объект 1 (ключ — InstanceID);
• в сессии прогоняются по нему анализаторы;
• оказывается, в нём есть какие-то ошибки;
• эти ошибки сохраняются в кэш по ключу 1;
• теперь, сколько бы сцена ни перерисовывалась (hierarchyWindowItemOnGUI), сессия будет давать заранее подготовленный ответ;
• в момент изменения сцены по hierarchyWindowChangedкэш сессии очистим, и информация обновится.

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

Осталось создать большущий префаб с теоретически бессмысленным уровнем вложенности и количеством дочерних объектов и гонять по нему анализ. Я в свое время предпочел собрать глыбу из почти 20 тысяч объектов, когда над каждым движением мыши редактор думал по 2 секунды. На таких масштабах уже неважно, сколько времени занимает анализ, — и без него невозможно работать. Потом каждый элемент системы (это и все отдельные анализаторы, и общий механизм их прогона) ускорял так, чтобы искры сыпались и молнии сверкали. Итого: на 2 секунды работы редактора приходилось 50 миллисекунд анализа.

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

Улучшения

Улучшали на основе сценария, когда на объекте был скрипт, а потом его удалили (или перенесли):

public sealed class MissingScriptAnalyzer : ComponentAnalyzer
{
    public override DiagnosticId DiagnosticId => DiagnosticId.MissingScript;

    public override IDiagnostic Execute(Component component)
    {
        if (ReferenceEquals(component, null))
            return Diagnostic.Error;

        return Diagnostic.None;            
    }
}

Подсказки

Первое соображение: одной иконки, очевидно, мало. Как и с булевскими да/нет — недостаточно исчерпывающе. Для начала неплохо бы использовать нативные подсказки Unity:

Код для такого анализатора немного меняется:

if (ReferenceEquals(component, null))
    return Diagnostic.Error
        .WithTooltip(“There is probably a missing script in game object.”);

WithTooltip в свою очередь оборачивает диагностику декоратором TooltipedDiagnostic (проще было — WithTooltipDiagnostic), где метод Drawделает сразу несколько вещей:

public void Draw(Rect rect)
{
    _diagnostic.Draw(rect); // Рисует декорированная диагностика.

    // Дорисовываем тултип.
    rect.y += 1;
    rect.height = rect.height - 2;

    var width = rect.height;
    rect.x += rect.width - width - 4;
    rect.width = width;

    var tooltipContent = new GUIContent(“”, _tooltipText); // Поле с текстом тултипа.

    GUI.Box(rect, tooltipContent, GUIStyle.none);
}

Метки

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

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

Реализуется тоже с помощью декоратора, а в MissingScriptAnalyzer к вызову WithTooltipдобавляется WithLabel:

if (ReferenceEquals(component, null))
    return Diagnostic.Error
        .WithTooltip(“There is probably a missing script in game object.”)
        .WithLabel(“MISSING”); // Вот это добавилось.

Глубокий анализ

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

Сворачиваем:

Отсюда новый вопрос: если на сцене лежит глубокая иерархия объектов, а я вижу только корневой, то что, если проблемный — один из самых закопанных?

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

Разворачиваем.

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

Исправления

Как же теперь не автоматизировать не только проверку ошибок, но и их исправление? У тех, кто работал с ReSharper, я уверен, в мозге есть отдельный нейрон, ответственный за Alt + Enter. С этой комбинацией клавиш связано всё теплое и душевное.

С ними, исправлениями, еще проще, чем с анализом, или по меньшей мере так же. Вот интерфейс:

public interface IFix
{
    DIagnosticId DiagnosticId { get; }

    void Execute(UnityEngine.Object context);
}

Выше мы описывали ContainsShadowAnalyzer. Теперь напишем для него фикс:

public sealed class ContainsShadowFix : ComponentFix<Shadow>
{
    public override DiagnosticId DiagnosticId => DiagnosticId.ContainsShadow;

    public override void Execute(Shadow shadow)
    {
        // Тут лучше заменять один компонент на другой, более эффективный.
        Undo.DestroyObjectImmediate( shadow );
    }
}

Вопрос тот же: когда выполнять? И если выделенный на сцене объект легко достается из Selection.activeGameObject, то с хоткеями не так уж просто. Во всяком случае, если в комбинацию включается Enter (обязательное условие).

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

Остается одно: импортировать user32.dll и использовать WinApi. Нам понадобятся такие методы:

1. GetActiveWindow — возвращает указатель на очередь сообщений активного потока приложения (или IntPtr.Zero, если в фокусе другое приложение), позволяет узнать, что сейчас активен именно редактор Unity.
2. GetKeyboardState — записывает в массив байтов текущее состояние клавиатуры (какие клавиши нажаты, какие нет).

Единственное, чего так и не получится сделать, — использовать Alt + Enter в качестве ключевой комбинации. Но Ctrl + Enter, как выяснилось, — отличная альтернатива.

Итого

Получилась бесхитростная и легкая система, направленная на две вещи:

1. Выискивать ошибки до того, как они попадут куда-либо.
2. Автоматизировать мелочи.

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

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

На этом всё. Спасибо за внимание! Пишите вопросы в комментариях.

Пример рабочей системы можно посмотреть на GitHub.

Эта статья о трудностях подбора кандидатов, причинах задержек и возможных вариантах решения. Она будет полезна рекрутерам, HR-ам, Hiring Manager-ам, СТО, СЕО, СОО. Да и в целом, для общего развития тем, кто хотел бы построить свою карьеру в IT-сфере.

Еще года три назад на то, что в Украине сложно найти человека (особенно в продукт), жаловался, по моей личной оценке, каждый третий работодатель. Сейчас же не гнобит рекрутера только тот, у кого набор персонала до 10 человек в год и то с распространенным стеком технологий.

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

Все данные приведены исходя из личной практики — моей и команды, ежедневной работы штата рекрутеров из 10 человек, личного комьюнити из порядка 450 человек и проработанной базы в 140 000 профилей за 4 года.

Как обстоят дела на самом деле

• Тысячи желающих войти в айти или недоразработчиков после курсов, неумеющих искать работу и презентовать себя, не понимающих, где же брать эти первые проекты и опыт.
• По-прежнему дикий спрос на middle и senior разработчиков. Кстати, на ура разбирают и juniors с опытом работы над своими проектами и готовыми работать за з.п. до $500 (ключевое слово «до») с английским на уровне понимания сериала «Silicon Valley» без титров.
• «Рынок разработчиков», которые диктуют условия и темпы, насколько быстро они могут быть наняты на новое место.
• Увеличение количества remote-вакансий, предложений работать как в офисе, так и вне его по желанию.
• Неистовый рост количества IT-рекрутеров, 90% из которых занимаются бездумной спам-рассылкой. Специальные расширения помогают находить почти что любой e-mail, и теперь разработчики не только удаляют профили в LinkedIn или перестают туда заходить, но и не защищены от бомбежки в личных почтах. Все это вводит разработчиков в уныние и вызывает еще большую нелюбовь к тем, кто не вникал в суть их профиля.
• Отсутствие стабильного известного поставщика рекрутинговых услуг, который из года в год мог бы гарантированно давать ожидаемый результат по «вменяемой цене».
• Все более учащающиеся кейсы, когда от момента собеседования до оффера проходит 2-3 часа.
• Наличие всем известных крутых продуктовых компаний с минимальной текучкой, суперусловиями, 9 кругами ада в отборе, понимающих, что такое Employer Branding и небольшой очередью из желающих к ним попасть. В Украине таких лично я могу назвать до 10, и в них менее 1% всех IT-специалистов рынка.
• Стоимость подбора 1-госпециалиста к себе в штат ежегодно растет. Если 4 года назад Java Senior стоил $2000-$3000, то сейчас эта цифра доходит и до $8000. И еще космические затраты при невозможности подобрать подходящих специалистов в срок. Одна из топовых украинских аутсорсинговых компаний в течение нескольких лет теряет миллионы в присейле из-за неподбора команд по embedded-разработке.
• Много клиентов / компаний заходит и уходит, столкнувшись с вопросами по подбору, менеджменту, качеству кадров. Для некоторых мы еще выгодны, а кто-то решает, что дешевле / менее рисково / более понятно по-английски / удобнее по часовой зоне работать с бразильцами, индонезийцами, поляками и пр. То есть происходит огромный mess и движение. Средняя продолжительность работы разработчика в компании — 1,8 года (у мобильных — 1,2 года). Иногда потому, что схантили или решил сам попробовать дороже продаться, иногда — из-за того, что закрылся проект или компания развалилась.
• Неготовность платить за объективную и обновленную информацию по рынку труда, уровню зарплат во всех регионах и данные, которые могут предлагать конкуренты. Неготовность платить за консалтинг.

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

Откуда проблемы и что со всем этим делать

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

Несоответствие требований и условий тому, что есть на рынке.В зависимости от того, какие сроки у вас на закрытие той или иной вакансии, должны быть соответствующие бюджеты, а уже потом процессы. Если вы хотите найти Senior Java Developer с английским в Киеве за $3500, будьте готовы искать долго и потерять его через полгода работы, когда схантят другие. Если ищите middle, помните, что рядом не всегда переборчивые работодатели, которым выгодно продать человека с 3-мягодами опыта как сеньора или тимлида без угрызения совести. Если вы уже 5-ймесяц ищете Rust разработчика, наверное, есть смысл перевезти его из России, Беларуси, Турции, Вьетнама или других стран. А бешеную нехватку Product Manager-ов — компенсировать опять же экспатами из США, Венгрии, Эстонии. Ввозить иностранцев вполне реально и быстро.

Неизвестность вашей компаниии непонимание того, что работа над Employer Branding — это отдельный системный труд, за который в упомянутых выше компаниях отвечают специальные сотрудники и выделяются существенные бюджеты. Без этого рынок не понимает, почему именно у вас есть смысл работать. Существует множество способов сарафанного и малобюджетного пиара, однако в случае с миллениалами это вопрос, суперстОящий фокуса вашего внимания и того, как распределять бюджет на следующий год. Становитесь открытыми и экологично транслируйте свою уникальность. No name компания — это всегда риски, это большое количество вопросов от соискателей. Если о вас нигде никто никогда не писал, это как минимум настораживает. То есть рекрутеру / hiring-менеджеру приходится тратить больше времени и аргументов для того, чтобы показать, что вы реальные люди с реальными ценностями, реальными тасками и приоритетами.

Слишком длинный и негибкий рекрутинговый процесс.Конечно, вам хотелось бы видеть резюме именно в такой форме, именно так выполненное тестовое задание и дать возможность пообщаться с новичком всем 17-тиспециалистам, которые будут с ним пересекаться. Однако эффективный рекрутинговый процесс не должен содержать более трех этапов и длиться более двух недель. А по возможности сократите до двух недель или одной. Тогда получится забрать тех, кто в активном поиске, и тех, кто успел влюбиться в вашу компанию на первом собеседовании. Это не прихоть рекрутера. Это то, что уже внедрили те, кто охотится за суперсильными разработчиками и кто вложился в свой бренд работодателя. При прохождении 7-9этапов собеседований на протяжении 2-3месяцев кандидаты сами неоднократно отказываются от сотрудничества, так как получали другие офферы / контрофферы.

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

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

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

Подпорченная репутация вашей компании.Плохие отзывы, статьи на «чудесном IT», «сарафан» из страшных историй и откровенное высмеивание в закрытых чатах прославившихся личностей или отдельных ситуаций. Когда ситуацию бросают на самотек и никто из компании ее не комментирует, это зачастую означает «крест» для подбора кандидатов. Настройте Google Alert с названием компании, реагируйте на каждый странный и злостный выпад со стороны тех, кто проходил у вас собеседование и не был принят; тех, кто был уволен и сильно раздосадован; тех, кто просто мимо проходил и решил вставить 5 копеек. Если не умеете это делать или не хватает времени, заказывайте отдельную услугу у PR-агентств или тех, у кого есть реальные примеры работы именно с IT-аудиторией, где не пройдет официозный тон и отсутствие чувства юмора. Не умеете работать с негативным шлейфом — проще сделать ребрендинг или быть готовым значительно переплачивать за найм и з.п.

Выводы

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

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

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

В рубрике DOU Проекторвсе желающие могут презентовать свой продукт (как стартап, так и ламповый pet-проект). Если вам есть о чем рассказать — приглашаем поучаствовать. Если нет — возможно, серия вдохновит на создание собственного made in Ukraine продукта. Вопросы и заявки на участие присылайте на editors@dou.ua.

Всем привет. Меня зовут Рома, я ex-Googler, который с головой ушел в образование. Работаю над Mate academy — школой, в которой учат программированию бесплатно, пока люди не найдут работу в tech.

С детства я сильно увлекался математикой. Участвовал и побеждал в международных олимпиадах. Любовь к математике перешла в любовь к кодингу, чем я и занимался на кибернетике в КНУ им. Шевченко. После учебы вместе с друзьями я начал создавать свой первый образовательный продукт — Preply.com. После года работы над Preply.com я получил оффер от Google, принял его и проработал там последние 5 лет.

Google — это, конечно, круто, но хотелось делать свой продукт. И тут мне очень повезло :)

Идея

В 2013-м Google перевел меня в New York. Моя жена Аня временно осталась в Украине, пока в визовом центре готовились ее документы. Планируя переезд и свою новую жизнь в США, Аня решила подтянуть технические навыки и пойти куда-то учиться. Выбрав технические курсы, она заметила несоответствие incentives (стимулов — ред.)у людей, которые пришли на курсы, и тех, которые их организовали.

Тогда мы подумали:

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

Так появилась идея Mate academy (первое название было EasyStartInIT). Как раз в это время Аня переехала ко мне в New York.

Реализация

Президент Y Combinator Sam Altman постоянно повторяет: «Best ideas often look terrible at the beginning». Задача основателя — доказать, что идея, которая плохо звучит, является правдой.

Я думаю, это во многом про Mate academy. Когда Аня делилась с друзьями идеей о том, что мы будем учить людей бесплатно, пока они не трудоустроятся, все, что она слышала в ответ: «Это не сработает», «Тебе никто не будет платить», «Только не в Украине», «Это у вас там в Америке так, у нас по-другому», «Менталитет тут другой» и т. д.

Но Аня не сдалась и следующие 2 года полностью посвятила Mate academy. Было тяжело: организация работы офиса, найм тренеров, поиск студентов, организация учебного процесса, помощь с трудоустройством после окончания. Заниматься этим из Нью-Йорка было еще сложнее. Решали задачи, как могли (и делали много ошибок). Тренеров брали из знакомых, программы обучения были слишком flexible. Все приходилось чинить на ходу (и до сих пор чиним, как в любом стартапе).

Команда проекта на старте

Финансирование

Дополнительной трудностью было финансирование проекта. Бизнес-модель предусматривает, что студенты учатся бесплатно до момента трудоустройства. После трудоустройства они оплачивают 10% от своей зарплаты на протяжении 3-хлет. Но затраты на проект начинались с первого дня. Нужен офис, где будут проходить занятия, нужно платить зарплату тренерам-программистам, носителям языка, которые учат студентов английскому и т. д. Сначала мы вложили свои $10 тыс. Но денег хватило ненадолго, так как новые группы студентов набирались (по 4-5человек в каждой) и требовали затрат, и даже с 90% employment rate разрыв в кеш-флоу был слишком большой.

Мы поняли, что нам нужно дополнительное финансирование, но заниматься фандрайзингом времени и желания особо не было. Все произошло как-то само собой. У нас как раз в то время гостевал Roman Koshlyak (приблизительно 200-йинженер Facebook), который, услышав о нашем проекте, предложил небольшую сумму инвестиций. Мы поняли, что это может быть интересно нашим украинским друзьям, которые работают в Facebook, Google, Amazon в США. Так и случилось. Мы нашли 5 инвесторов среди наших друзей-инженеров, которые вложили небольшие суммы для развития проекта.

Спустя 2,5 года 100-йвыпускник школы трудоустроился. Я понял, что мы прошли точку невозврата. В 2018 я сделал leave notice в Google, и мы с женой решили вернуться в Украину и полностью заняться развитием Mate academy. Мы увидели в проекте реальную возможность повлиять на образование в стране. А может, и не только в стране.

Лучший студент последней школы — интерн-патологоанатом. Среди выпускников были в прошлом грузчики, повара, безработные, студенты и работники McDonalds. Были и ребята с техническим образованием, но без навыков программирования. При правильном подходе научиться может каждый, у кого есть очень большое желание учиться и работать над собой, а также подлинный интерес к программированию.

Процессы в школе

Формат обучения:

• Вечернее, 2,5 раза в неделю (6-7часов в неделю).
• Формат полного дня (40+ часов в неделю).

Принципы:

• Learning by doing (минимум лекций возле доски, теорию даем на самостоятельную обработку дома, каждый урок начинается с разбора вопросов по заданным материалам).
• Small groups (исторически средний размер группы был 5-6 человек).Можно больше, но у нас не будет больше 10.
• Coaches vs lecturers (задача — дать знания и трудоустройство, а не сам процесс обучения. Обучение заканчивается, когда 60% в группе нашли работу. Coaches получают бонусы, когда их подопечные находят работу).
• Групповые задания и Demo project (ребята работают над проектом для портфолио до окончания школы).
• 90% студентов находят работу уже через 3-5 месяцев.Но это не значит, что они уже профессионалы. Мы продолжаем работать с ними и предлагаем дополнительные курсы для развития их навыков (сейчас это React, Angular, Algorithms etc).
• Программа. Не так важна, как принципы обучения. Мы выбираем крутых Coaches, просим их следовать нашим принципам и даем достаточно flexibility в вопросе программы.

Длительность: 3-4 месяца.

Направления: Front-end, Java, Full stack. От QA отказались, так как решили сконцентрироваться на инженерном обучении.

Группы: было 4-6 человек,сейчас тестируем 8-10.

Тренеры (мы их называем Coaches): люди с любовью к преподаванию, 5+ лет опыта, Middle+ или Senior специалисты. В основном наши знакомые, которые потом рекомендуют своих знакомых. Они получат зарплату + бонусы за каждого студента, который нашел работу во время курса.

Что еще предлагаем, кроме обучения:

• За каждым студентом закреплен HR, который помогает с резюме, LinkedIn, cover letter, интересными вакансиями и стресс-интервью перед собеседованием. Есть компании, с которыми мы тесно сотрудничаем и отправляем туда наших выпускников, но мы не привязываемся только к ним, и окончательное решение всегда за студентом.
• Постоянные уроки английского с носителями языка.

Оплата

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

Нас часто спрашивают:

«Как вы проверяете, не обманывает ли вас выпускник?».Пока никак. Пока почти все платят, как договорились, потому что чувствуют ценность, которую мы предоставили и продолжаем предоставлять. У нас 2-3проблемных кейса из 136 трудоустроенных.

«Что, если человек поменял работу?». Отлично. Мы первые об этом узнаем, потому что он приходит на тестовое интервью и получает инфо от нас, что ему нужно подучить, чтобы попасть туда-то, насколько наши выпускники рады работать там-то, на какую зп со своими знаниями он может претендовать и т. д.

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

«Что если, человек прекращает работать?». Ок, договор рассчитан на 36 месяцев, а не 3 календарных года. Если человек увольняется по каким-то причинам, оплата приостанавливается до момента, когда он опять начнет работать в технологической компании.

Результаты

• 136 людей — обучились и нашли свою первую работу в Tech.
• 90% и больше наших студентов находят работу после завершения обучения в Mate academy.
• NPS (Net Promoter Score) — 79.
• На 8% зарплата наших выпускников выше, чем по рынку, согласно статистике DOU, даже после выплат Mate academy.
• Мы попали в YC Startup School Advisors Track и будем учиться, как работать еще круче.

Планы на будущее

Очень хочется реализовать 3 вещи:

1. Запускать новые направления (Full Stack, Data Science) и делать это не только офлайн, но и переходить в онлайн-формат обучения. Чтобы люди даже из деревни в Карпатах имели доступ к world-class бесплатному обучению тому, что даст им возможность работать в tech.
2. Экспериментировать с длительностью курсов и объемом знаний, которые получает на выходе студент. Становиться настоящей альтернативой высшему образованию.
3. Не останавливаться на Украине. В мире миллионы способных людей, не имеющих возможности получить качественное бесплатное образование, после которого топовые компании соревнуются за тебя.

Если вы поверили в наш проект и хотите стать частью Mate academy — напишите нам! Мы ищем людей с 5+ лет опыта в программировании, которым не безразлично образование и которые готовы помогать запускать новые образовательные направления (Full Stack, Front-end, iOS, Python, Data Science).

По любым вопросам мы доступны:

• max@mate.academy
• www.facebook.com/mateacademy

Давайте вместе починим Computer Science education.

Если оставить в стороне техническую сторону дела, то украинское IT отличает две характерные черты:

1. Отношения айтишников с остальным обществом. Айтишная зарплата в нищей стране — пропуск в сытую жизнь. Одним — «dolce vita», другим — «оковита».
2. Отношения айтишников между собой. Скрытое соревнование и желание прикрыть уязвлённое самолюбие. Это и желание писать только на самых модных языках и технологиях («не на пыхе же говнокодить!»), и едкий сарказм в комментах на ДОУ, и его кристаллизация в виде появления сайта ebanoe.it.

Это проблемы взросления. Бывает и по-другому. Давайте сравним украинские и датские айтишные реалии. Я прожил в Копенгагене 5 лет, за это время успел поработать СТО в датском стартапе (holiday rentals industry), а также разработчиком в IT-отделе датской телекомпании TV2. Есть чем поделиться.

Отношение к работе

Был такой анекдот. Выходят с конференции датчанин с украинцем (не будем показывать пальцем). Датчанин спрашивает:

— What did you get from the conference? («Что ты вынес с конференции?»)

— Две футболки, кружку, пару ручек и мячик c логотипом Postgres для сына.

Что-то мне подсказывает, что датчанин спрашивал не про сувенирку...

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

Давайте посмотрим правде в глаза: нам всё время что-то недодали. Поэтому мы отчаянно пытаемся восстановить справедливость в свою пользу.

Поэтому украинский стиль работы в IT предполагает поиск добычи и определённую раскачку за счёт работодателя. Рассмотрим примеры. Принять 3 офера, выбрать лучший, остальные отменить. Усердно заниматься спортом «перебежки в соседнюю контору за +$100 к зарплате». Прийти на работу к 12 (главное — успеть до стендапа). Первый час потратить на кофе и Фейсбучек, это святое. Сесть спиной к стене, чтобы не заглядывали в монитор. Как-то отсидеть 8 часов за рабочим местом («всё равно программист выдаёт в день не больше  6  5  4  3 эффективных часов работы»). Весь год ходить в бесплатных корпоративных футболках. Утащить пару бутылок вискаря под закрытие корпоратива себе в отдел (добыл!). Работать на ломаном Windows или IDE. Качать торренты без регистрации и SMS, иногда кладя на лопатки офисный интернет-канал. На курилке обсуждать невыученный урок коммунизма«Почему не мы, а IT-компания получает такие большие прибыли, если это мы делаем всю работу?». Ну и не забыть пожаловаться, что ты раб на галере.

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

В Дании по-другому, как-то более по-взрослому и при этом от души. Например, начинают работать сразу, вот прямо с 9 утра. Не «прийти на работу к 9», а именно начать что-то педалить.

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

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

В атмосфере не витает вот это вот «Я на этом проекте временно. Найду зарплату получше — и поминай как звали». Такое впечатление, что датчане выбирают место работы по душе, и потом просто спокойно работают. Как-то вот они работают в кайф, поскольку датское IT не является золотым билетом. Как я уже говорил, в SimCorp есть люди, работающие там с 70-80-х годов. И в IТ Дании это не редкость.

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

Делать то, что тебе нравится, в кайф. На сайте TV2 есть страница, где в тёплое время года показываются данные по пляжам всей Дании: температура воды и воздуха, сила ветра и т. д. Около 200 точек на карте. Когда я посмотрел в базу данных по каждой точке, там помимо прочего было поле с номером телефона. Оказывается, эти данные каждое утро присылают SMS-ками энтузиасты, у которых есть метеостанции. Бесплатно. Просто им в кайф. На этом построен сервис, и эти данные показывают по телевизору.

Ещё не разу не видел, чтобы датчане делали заначки рома и виски после корпоратива. По-настоящему богатый человек внутренне расслаблен: если ему захочется выпить с коллегами, они пойдут в бар или просто купят,то что им нужно (лайфхак!).

Так же никто не обеспокоен закачкой торрентов или пробросом VPN, чтобы «просто слушать музыку» из «ВКонтакте». Датчане платят несколько долларов за Netflix и Spotify и чувствуют себя жителями страны первого мира.

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

Например, был случай, когда ТОП-менеджер TV2, второй человек в фирме, седовласый и уважаемый (20 лет в компании), попал в сексуальный скандал. Его откровенные фотки оказались у журналистки в компании конкурентов. В Украине такая история обросла бы слухами, а дядя бы извивался как уж на вилах. Что делают датчане? Сам ТОП-менеджер прямо все рассказывает и подает в отставку (чтобы конкуренты не могли через него шантажировать компанию), а наш ПМ на утреннем совещании объявил: «Вы в курсе, что произошло. Хорошие новости: наш сайт побил рекорд посещаемости, и мы смогли лишний раз проверить работу load-balancer». В общем, вопрос был закрыт.

Территориальная агрессия

Дальше. Вы замечали, что нас, украинцев, отличает территориальная агрессия? Что если вы приходите, а кто-то взял ваш стул и нагло на нём сидит? «Это же мойстул».

В Дании этот условный стул — не Entity, а просто Value Object. Он не мой, не твой, а компании, и вообще они все одинаковые. Были случаи, когда кто-то брал стул менеджера (!!!!), чтобы толпой обсудить какие-то вопросы за соседним столом. И ничего, не подгорало у нашего шефа. Просто брал другой стул или работал вообще стоя эти 10 минут. Его самолюбие не уязвлено. Он отвечает за самый большой сайт Дании. Стул не имеет значения.

Отличительная фишка Европы — класть ноги на стол или соседние стулья (потому что чисто). В Дании их могут класть ещё и на стол собеседника — и собеседника это не трогает прямо вообще никак.

Первые месяцы в Украине мне регулярно делал замечание украинский шеф, чтобы я не вёл себя слишком вольно — «это тебе не Дания».

Fredags Mad

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

Один из них — Fredags Mad [фредагс мэл], «пятничная еда». Я встречал его во всех компаниях, где работал. Только некоторые проводили его в пятницу, а кто-то начинал с него рабочую неделю в понедельник.

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

Хотя ритуал очень простой, я заметил у него несколько полезных функций.

Во-первых, у команды есть возможность пообщаться и синхронизироваться по широкому спектру тем. Стендап слишком формален. А вот Fredags Mad — идеальное время, чтобы:

• Лидер команды мог рассказать последние новости с совещания с боссами, и полушутя-полусерьёзно обрисовать макроситуацию.
• В стартапе «продажники» просто выдавали нам (остальной команде) важные цифры — куда вообще движется компания.
• Для линейного сотрудника это удобное время объявить о своём увольнении или наоборот — о пополнении в семье (это и мило, и часто несёт за собой сдвиги в работе команды, так как в Дании в декрет могут уходить и мужчины).
• Отличный момент обсудить рабочие сплетни, курьёзы, планы на выходные и прочее.

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

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

Я пробовал организовать такой Fredags Mad в украинской IT-компании. Тяжело-о-о идёт.

Одна часть коллег («вечно голодные») воспринимают это как продолжение халявных кофе и печенек, поэтому не берут на себя роль быть следующим по очереди («а зачем?»), и на них новая традиция тухнет.

Вторая часть коллег не чувствует необходимости открываться другим: «Я доел, можно я теперь пойду?».

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

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

Общение

Датчане верят, что «communication is the King». Это, в частности, включает в себя такие явления, как small talk и active listening. Умеют они растопить лёд, когда все собрались и начали говорить, но ещё не настроились на общий лад. Умеют слушать так, что ты понимаешь — тебя слышат. Ты понимаешь, что такое роскошь человеческого общения.

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

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

Не ешьте в одиночку

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

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

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

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

Удовольствие от работы

Отличительной частью датской культуры является понятие «arbejdsglæde» [арбайдс-глэль], то есть удовольствие от работы. Считается, что работник будет выдавать результаты лучше и дольше, если он испытывает чувство счастья и принятия группой.

Работа и общение должны быть «хюггли» (уютными). Гармоничная красота офиса, чистота и ухоженность, чувство безопасности — всё это работает на повышение коэффициента удовольствия от работы. Этот коэффициент регулярно измеряют методом опросов. В нашей команде он был 87%. Так как этот показатель был на 2% меньше, чем в среднем по компании, наш шеф дополнительно собрал команду, чтобы выяснить болевые точки и устранить их.

Из моего личного опыта таких ярких моментов было несколько. Когда я только устроился в TV2 (а выйти на новую работу в Дании, как правило, можно только с первого числа нового месяца), мой новый шеф сказал мне, что вся команда 29 сентября едет в Амстердам на конференцию. Поэтому он посоветовал мне взять отпуск на 2 последних дня сентября на старой работе и поехать вместе с ними. Несмотря на то, что я фактически ещё не числился в штате, мне оплатили дорогу, проживание и участие в конференции. И технологию я подтяну, и с командой познакомлюсь в неформальной обстановке. Я оценил.

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

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

А ещё для повышения уровня arbejdsglæde в офисе есть массажный кабинет с 4 видами массажа. Бесплатно.

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

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

Вот, например, у нас выступает американец Brad Frost, автор концепции иерархического UX-дизайна «Atomic Design». Сначала он изложил матчасть с картинками, а потом мы разбирали примеры. Всё неформально, с перерывами на тортик — arbejdsglæde же!

Спорт

Говорят, где 2 украинца, там 3 гетмана. В Дании не так: где 2 датчанина, там 3 клуба по интересам. У нас был даже клуб коллекционеров живописи, и в TV2 на стенах постоянно висела сменяющаяся экспозиция, которую потом скупали члены клуба.

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

Что удивило в спорте, так это массовые городские мероприятия. Например, DHL Stafetten — эстафета на 5 км для команд из 5 человек, организованная под эгидой компании DHL. Фишка в том, что каждая компания в городе, крупная и не очень, выставляла свои команды, и стадион Parken ненадолго становился маленьким олимпийским городком. В Украине тоже становятся популярными марафоны среди компаний, но до копенгагенской массовости нам пока бежать и бежать.

Вот мой короткий репортаж, как это выглядит:

Что интересно: помимо этого каждая компания также ставила свой тент с пивом и барбекю, так что общегородское спортивное мероприятие становилось массовым пиво-принятием. Я слышал, что датские бомжи, которые слетаются на такой массовый ивент собирать банки из-под пива, поднимают в сумме 100-200тысяч крон (1 банка — 1 крона), то есть $15-30 тысяч.

Если оставить пиво в стороне, то спорт очень популярен и пронизывает жизнь каждой компании и каждого отдельно взятого человека. По этой причине датчане в среднем живут на 9-12лет дольше украинцев. Ну и бесспорно, это объединяет коллектив. Например, в Дании коллеги могут договориться пробежать Iron Man вместе, а в Украине это, как правило, спорт личного достижения. Чувствуете разницу?

Офис должен вдохновлять

Ну и конечно, расскажу про офис, так как там мы проводим треть суток.

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

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

Внутри офис TV2 выглядит как огромная «пропасть». Философия такого интерьера — захватить максимум солнечного света и чтобы у всех было место у окна.

Такую смелую архитектуру в Украине не купишь. Разве что взять старый завод и переделать в огромный лофт, но это нужно очень этого хотеть. Другой офис TV2, в городе Оденсе на острове Фюн, как раз был переделан из старого здания рынка скота. И по закону они обязаны были сохранить в стене раритетную лебёдку для подъёма коров.

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

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

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

Вот, например, зона отдыха. (Горизонт я сам завалил).

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

Был в фойе обожаемый мной бассейн с мини-водопадом. Кому он мешал?

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

Нужно повысить безопасность сотрудников — ставим «бронепробиваемые» стёкла и турникеты. Именно в Дании началась история стрельбы за шутки про Мухаммеда, а датчане слишком любят свободу слова.

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

Помимо этого, датчане просто выкидывают много устаревшей техники, и я просто не мог пройти мимо. Теперь десятки «спасённых» роутеров радостно мигают лампочками в киевских и днепровских школах Украины. Есть идея просто организовать точку приёма устаревшей по датским меркам техники и везти к нам в рамках помощи развивающимся странам.

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

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

Или даже полежать, если попа затекла от сидячей работы.

Сам офис достаточно технологичен. На ресепшене тебя регистрируют и выдают вот такой бейджик. Его нужно наклеить на видное место на одежду. Так все делают, чтобы если человек без бейджика, можно было подойти и спросить: «Онскюльте, конечно, но вы кто?». На бейджике написан ваш временный пароль к местному вайфаю. Мелочь, а приятно. Ну и плюс контроль, чтобы не скачал случайно торрент какой-нибудь с корпоративного IP.

Как я уже говорил, датчане творчески используют офисное пространство.

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

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

Негласно, датский офис — это всегда место для шалостей и творчества.

К шалостям относятся и провокационные постеры на стенах. Датская культура — достаточно раскрепощённая. Поэтому не пугайся, когда видишь постеры сериалов местного производства.

Вот видеообзор, как офис выглядит изнутри:

Почему датчане такие?

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

Украинская же цель — «не проиграть».

Кстати, вот это желание «не проиграть», «не подставиться», является одной из причин, почему мы тяжело идём навстречу новым контактам. Например, у датчан личный номер телефона часто указан на Facebook-странице, а у украинцев — практически никогда.

Да, мы сейчас такие, ничего страшного. Другие через это уже прошли. Например, в английском языке есть старое слово «to cabbage», которым называют воровство офисных принадлежностей (изначально — остатков ткани портными).

Когда-нибудь и мы наедимся.

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

Олег Федотов, Engineer Level 2 в CoreValue

18 лет опыта в ІТ, из них 5 — в DevOps

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

• TCP/IP — очень важно понимать, как работает сеть (классический вопрос на собеседовании — Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com). Вот Cisco CCNA курс, достаточно именно TCP/IP раздела.
• Linux (дистрибутив не имеет значения, главное — свежий). Лично мне очень помогло в своё время понимание, что происходит под капотом во время загрузки операционной системы. «Linux from Scratch», — наверное, лучшее из бесплатного, но придется с ней повозиться.
• Python — наверное, самый простой в изучении и одновременно самый востребованный язык в мире DevOps и не только.
• AWS — облачная инфраструктура, которая очень сильно упрощает жизнь DevOps инженеру, беря на себя огромную часть рутинных задач. При этом так называемый AWS Free Tier даёт возможность новичкам абсолютно бесплатно пощупать львиную долю сервисов. Для меня идеальным в изучении оказался курс AWS Certified Solutions Architect — гайд к нему.

Это далеко не всё, но достаточно для уверенного старта. А впереди Docker, Ansible, Jenkins и пр. — это те технологии, изучать которые будет намного легче, освоив базу. А дальше ITIL, DevOps методологии и еще много-много интересного и важного. И я нарочно не упомянул Windows! Я считаю, что освоив Linux, освоить Windows будет куда легче, но не наоборот.

Дмитрий Замаруев, Technical Director, Cloud Solutions в Grid Dynamics

Более 14 лет опыта в ІТ

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

Наиболее часто компании на позицию «DevOps Engineer» ищут людей, которые будут отвечать за CI/CD инфраструктуру для проекта/компании, заниматься доставкой приложений (deployment engineer) или автоматизировать создание инфраструктуры (infrastructure engineer). Это все самодостаточные отдельные специализации, о каждой из которых можно долго говорить.

Попробуем обобщить знания, которые помогут инженеру начать разбираться в этих областях. DevOps охватывает много определений: это и continuous delivery (CI/CD), и infrastructure automation, и configuration management:

• Совсем базовые знания — Computer Science. Любая работа в области информационных технологий подразумевает базовые знания в области компьютерных наук. Если в институте этот предмет «не зашел», то можно посмотреть курс CS101от Stanford University — он находится в свободном доступе и дает хорошее понимание основ.
• Scripting basics — без написания скриптов в век тотальной автоматизации никак не обойтись, поэтому не нужно бояться командной строки и написания собственных скриптов. Если что-то нужно сделать больше, чем один раз, это нужно автоматизировать.
• Для тех кому мир Linux Shell совсем не известен: Intro to Bash, Bash scripting tutorial.
• CI/CD — непрерывная интеграция и доставка приложений сейчас тесно связана с понятием DevOps, поэтому необходимо понимать, что это такое и для чего нужно. Концепция отлично описана в книге Фаулера «Continuous Delivery». Если книгу не достать, то основные концепции описаны у автора на сайте (сайт вообще весь хороший, советую прочитать от и до).
• Инструментарий для непрерывной интеграции довольно разнообразный, но лидирует с большим отрывом Jenkins, поэтому советую начать изучение именно с него. Вместе с этим крайне желательно ознакомиться с системами сборки тех языков, с которыми планируется работать, так как это одна из точек соприкосновения с разработчиками (Maven/Gradle/sbt/CMake etc.).
• Clouds — современная инфраструктура уже давно вышла за пределы дата-центров. Поэтому без опыта/знаний облачных провайдеров сейчас мало что можно сделать. Благо крупные провайдеры предоставляют пробные периоды на доступных условиях и попробовать, что такое облако, можно легко. А главное, что бесплатные планы можно использовать для изучения различных инструментов и оттачивания навыков.
• AWS предоставляет 1 год использования некоторых типов ресурсов совершенно бесплатно (но нужно настроить оповещения на возможную оплату, так как доступны и платные ресурсы, которые по незнанию можно случайно запустить).
• Google Cloud дает кредит $300 сроком на один год на любые ресурсы — этого вполне достаточно для обучения.
• Microsoft Azure — $200 на месяц — немного по времени, но достаточно, если нужно просто познакомиться с системой.
• Infrastructure automation — автоматизация создания инфраструктуры тесно переплетается с понятием infrastructure-as-a-code. Описание инфраструктуры кодом пытается решить проблему повторяемости, тестирования и ревью, то есть применить принципы CI/CD для уровня инфраструктуры (ссылка на Фаулера).
• Из инструментария наиболее популярными, наверное, являются поделия-на-коленке и Terraform — к нему-то и стоит присмотреться.
• Configuration management — создание повторяемой и предсказуемой настройки системы/приложений. Также большинство инструментов из этой области могут использоваться для автоматизации доставки приложений (deployment automation). Изучение стоит начать с Ansible, так как у него ниже порог вхождения. Но также следует его сравнить с похожими инструментами, такими как Chef и Puppet.

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

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

Евгений Волченко, DevOps Engineer в Luxoft Ukraine

12 лет в IT, 5 лет опыта в DevOps

3 must-have навыка

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

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

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

Чего делать не надо

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

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

Снова же, из-за того, что DevOps специалистов на проектах зачастую не больше одного, возникает некий вакуум общения с коллегами, интересующимися девопс-направлением и технологиями. Несмотря на противоречивое отношение к профильным мероприятиям, я рекомендую не пренебрегать ими. Митапы, конференции — все это подойдет, особенно, на первых этапах. Как я говорил, DevOps должен сам заниматься своим развитием, иногда даже больше, чем другие специалисты. Программистам разного профиля проще найти более опытных коллег, которые направят и подскажут, даже в рамках одного проекта. По опыту добавлю, что не стоит игнорировать и навыки программирования. Знание архитектуры Web-приложений и умение работать с Rest API точно пригодятся.

Что почитать

С первой книгой начинающим DevOps’ам повезло — она написана в художественном стиле и вряд ли когда устареет. Это «The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win»авторства Gene Kim. Для понимания этапов и процессов в production рекомендую «Site Reliability Engineering: How Google Runs Production Systems» Niall Richard Murphy. И книга по программированию — «Go in Practice: Includes 70 Techniques», автор — Matt Butcher. Чтобы быть успешным DevOps специалистом, нужно уметь программировать хотя бы на базовом уровне.

Антон Чудаев, TeamLead DevOps в V.I.Tech

8 лет опыта в Ops + 4 года в DevOps

В DevOps часто приходят либо из программистов (Dev), либо из админов (Ops). Так получается, что это смесь и культура разных направлений, поэтому и изучать новые технологии DevOps инженеру приходится быстрее, чем рядовому айтишнику. Еще накладывается зависимость от конкретных технологий, используемых в проекте. Я советую изучить хотя бы одну тулзу в каждой области, а уже потом расширять и углублять знания по мере необходимости.

Публичные облака. Вычислительные ресурсы — это основа, на которую дальше все накладывается. Если выбор пал на «Амазон» (как в большинстве случаев), то дождитесь скидки и купите курс по AWSза 10$. Он даст общее представление о сервисах и ресурсах. Для автоматизации развертывания и поддержки инфраструктуры (Infrastructure-as-Code) используйте нативный для AWS CloudFormation — будет проще начать и всегда up-to-date. Если не «Амазон» или не желаете вендор-лока, то используйте Terraform.

После того как «сетку раскинули», инстансы подняли, нужно упаковать аппликацию. Тут нам помогает контейнеризация. В этой области правит Docker. Начните с простого создания имиджей и деплоя контейнеров и уже по мере запросов от бизнеса переходите к кластеризации и сервисам в Kubernetes.

Чтобы управление и настройка сервера/сервисами были прозрачными и стандартизированными, используйте тулзы для config-менеджмента. Мой фаворит, особено для начинающих — Ansible.Изучайте примеры на Ansible Galaxy и пробуйте модифицировать их на своих рутинных задачах. Из альтернатив — SaltStack или Chef.

Уже построенный work-flow сборки, тестирования и деплоя нужно упаковать и красиво визуализировать с помощью пайплайнов, например вот пайплайн для Дженкинса. Это поможет масштабировать процессы на разные энвайронменты.

Мониторинг. Следить и поддерживать сервисы поможет, если еще не внедренный, старичок Zabbix. Также посмотрите на более новые: Prometheusили TICK Stack.

Главная задача девопса — ускорение доставки продукта от бизнеса до потребителей. Автоматизация — это только одно из основных средств, а не самоцель. CI/CD, blue-green, Phoenix, Canary Deployments — это тоже средства, которые возникают по мере необходимости. Чтобы это почувствовать, понять философию DevOps культуры, помогут классические книги:

• «The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win» by Gene Kim, Kevin Behr, George Spafford;
• «The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations» by Gene Kim, Patrick Debois, John Willis, Jez Humble;
• «Site Reliability Engineering» edited by Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy.

При этом всегда нужно «смотреть в завтрашний день» и следить за новинками, но не перегружать бизнес гонкой за трендами, если он пока еще не дорос до таких потребностей.

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

• CatOps;
• UkropsDigest;
• ДевОпс Инженер;
• DevOps&SRE Library.

Hints&tips

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

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

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

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

Сергей Марченко, Head of IT Department в Dev-Pro

6 лет опыта в IT

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

Мой план с рекомендациями, как освоить специальность:

Сначала Ops, потом Dev

Заказчики постоянно беспокоятся про uptime, безопасность, в общем, обычный IT Operations никуда не делся. Поэтому сначала понадобятся хорошие знания системного администрирования, troubleshooting и поиск bottlenecks. Infrastructure as a code, CI/CD и прочее стоит рассматривать как продолжение карьеры системного администратора, а не отдельный путь.

Не стоит становиться человеком, который разворачивает инфраструктуру MySQL High Availability на Ansible, не понимая, как работает репликация. Что уж там, иногда даже процесс резервного копирования базы вызывает вопросы. Изучайте основы networking, Linux/Windows, web servers (NGINX, Apache), DBs, monitoring и только потом DevOps практики.

Clouds

DevOps почти равно Clouds. Поэтому стоит разобраться хотя бы с одним Cloud Provider — AWS, Azure, Google Cloud Platform. У AWS можно зарегистрировать Free Tier, которого достаточно, чтобы познакомиться с этой платформой.

Automation

Во время изучения Cloud Platforms стоит обратить внимание на Configuration Management and Provisioning Tools. Я бы рекомендовал Ansible и Terraform. Вместе с изучением Terraform советую смотреть на контейнеры, Docker, Kubernetes — это позволит лучше понять сильные стороны Provisioning Tools.

Копайте вглубь

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

Пишите код

Кроме кода, который необходимо писать для разворачивания новой инфраструктуры, стоит подумать про написание своего приложения. Тут поможет какой-нибудь Pet Project. Это может быть веб-сайт, чат-бот или IoT-приложение, которое доливает воду в кофеварку (в IТ-компаниях и не такое встретишь). Главное — глубже понять работу и проблемы разработчиков. Для написания такого приложения я бы предложил воспользоваться языком, который потом пригодится DevOps инженеру: Python или Golang в самый раз. В случае Go забудьте про книги, A Tour of Go — то, что вы ищите.

Читайте чужой код

Изучая Terraform, я подсмотрел tips and tricks, хорошие практики из Terraform Module Registry. Чтение чужого кода позволяет посмотреть другие практики и, если они окажутся лучше ваших, перенять их. Кстати, говоря о Terraform, я бы рекомендовал начать с Terraform: Up and Running.

Security

DevOps подходы ускоряют разворачивания инфраструктур и добавляют еще больше проблем для Security Engineers. Так что стоит сразу избавляться от простых ошибок, например, не класть ключи и секреты в открытом виде в version control, немного углубиться в тему security. Тут вам помогут ключевые слова DevSecOps, OWASP, Key Vault.

Сообщество

Когда вы определитесь со списком software, с которым вы работаете, стоит принимать активное участие в жизни продукта. Читать форумы (Stack Overflow), следить за обновлениями на GitHub, возможно, даже контрибьютить свой код.

Не решайте проблем, которых нет

AI, Big Data... в мире столько новых течений. Как тут удержаться и не внедрить что-то новенькое в свой проект. Мой совет — внедряйте только то, в чем вы действительно нуждаетесь, вы должны знать, какую проблему решаете. Большинство модных технологий вам не нужны или не подходят. You are not Google.

Максим Зинькевич, Lead Systems Engineer в EPAM Kharkiv

5 лет опыта в DevOps

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

Еще будучи студентом, я работал системным администратором в различных бизнесах. Начинал с Windows и Linux. Постепенно перешел к поддержке серверов и автоматизации. Когда я впервые использовал такие инструменты как Puppet, Jenkins, системы контроля версий (Subversion, Git), ко мне пришло осознание, что за гранью сисадминистрирования есть огромный мир DevOps. Чтобы двигаться дальше, я присоединился к EPAM. Именно тогда, 5 лет назад, в компании запускалось пилотное направление DevOps. Сейчас мы активно развиваем эту компетенцию внутри компании.

Опираясь на свой опыт, мои рекомендации начинающим специалистам будут выглядеть так:

• Выбирайте работодателя и проекты, которые будут вас профессионально формировать. Все мои смены работы были продиктованы исключительно желанием развиваться. Как только чувствуете, что начинаете деградировать — меняйте работу.
• Не бойтесь браться за новые или сложные проекты, которые выше вашего уровня. А лучше всего сразу подключаться к нескольким проектам. Такой активный режим очень поможет в прокачке практических знаний и навыков. Но не забывайте о балансе, чтобы быстро не перегореть.
• Задавайте вопросы вашему ментору / лиду проекта / тимлиду. Если в течение двух дней вы не задали вопрос по тому, что вам непонятно — вы потеряли два дня в познании профессии, и кому-то придется переделывать вашу работу. Отбросьте стеснение, абсолютно все начинали так же, как и вы. Будьте инициативны и любознательны.
• Учитесь на своих ошибках. Завершили проект — проанализируйте, что было сделано хорошо, а что можно и нужно улучшить. Подход continuous improvement должен стать неотъемлемой частью проектной работы.
• Выучите или доучите такие несложные языки программирования, как Ruby и Python. Python и так давно уже используется в системном администрировании. Почему Ruby? Системы автоматизации Puppet и Сhef используют DSL, основанный на Ruby, поэтому некоторые тонкие вещи придется писать на этом языке. Хоть программирование в основном и функциональное, но без основ объектно-ориентированного программирования развиваться в DevOps будет сложно.
• Следите за авторами и читайте профильные материалы на Habrи DZone. Там же есть подкасты и видео.
• Пройдите обучающие курсы на Courseraи Codecademy.com.

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

За весь свой опыт работы я прочитал только одну книгу «Непрерывная интеграция» Jez Humble, David Farley. Она очень легко читается и будет понятна начинающим специалистам. Там еще используются примеры старого ПО, но все принципы будут актуальны и сегодня. Она мне помогла структурировать уже имеющиеся знания. Остальное же — практика, актуальные статьи по теме, документация и, конечно же, коллеги.

[DOU Hobby — рубрика о нетехнических проектах IT-специалистов: творчество, интересное хобби и другие lifestyle-достижения. Если вам есть о чем рассказать — пишите на valentina@dou.ua]

Петр Корякин — Ruby Developer в харьковском офисе компании SoftServe. В свободное время он играет в плейбек-театре, где все строится на импровизации: зрители рассказывают истории, а актеры превращают их в художественное произведение на сцене.

— Петр, что такое плейбек-театр? Чем он отличается от обычного?

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

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

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

Актеры и остальные зрители тоже слушают историю впервые — времени на обсуждение и обдумывание нет.

— Что происходит дальше?

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

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

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

— Есть ли какие-то общие правила, принципы, как проводить плейбек?

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

Она включает четыре фактора:

• спонтанность;
• управление;
• история;
• атмосфера.

Между факторами нет иерархии. Они одинаково важны и влияют друг на друга.

Четыре принципа плейбека

— Как вы заинтересовались плейбеком? С чего все началось?

Однажды Facebook подкинул напоминание о мероприятии, которое происходит поблизости. Это оказался перформанс плейбек-театра «Вахтеры».

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

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

Пару месяцев спустя тот же Facebook подкинул анонс однодневного 10-часовогоинтенсива по плейбеку, на котором были упражнения, игры, объяснялась теория плейбека. На интенсиве каждый участник мог попробовать себя в амплуа зрителя, актера, рассказчика, кондактора.

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

— Чем вам нравится плейбек? Как вас изменило это хобби?

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

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

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

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

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

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

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

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

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

— Каких навыков требует плейбек? Сколько времени нужно, чтобы достичь мастерства?

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

Одновременно происходит работа с психологическими параметрами: развитие эмоционального интеллекта, знакомство с понятиями проекций, переносов.

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

— Бывают ли как-то полезны полученные в театре навыки в жизни, на работе?

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

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

— Как удается совмещать хобби и работу? Много ли времени уходит на репетиции?

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

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

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

— А как обычно проходят репетиции по плейбеку?

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

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

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

— Развита ли в Украине культура плейбек-театров? Много коллективов?

Да, в Украине достаточно развито плейбек-сообщество. Но оно не большое: около 30 театров.

Первый театр был основан в 2001 году в Киеве. Наиболее активное развитие началось с 2009 года. Сейчас идёт активная работа по созданию украинской плейбек-школы.

— Что можете посоветовать новичкам, которые начинают интересоваться плейбек-театром? С чего и как лучше начинать, на что обратить внимание?

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

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

Еще несколько советов — в видеоНаталии Вайнилович.

— Какие у вас планы на будущее, связанные с плейбек-театром?

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

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

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

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

Эта статья будет полезна в первую очередь Project Manager-ам, Scrum Master-ам, проектным аудиторам, а также другим специалистам, которые хотят понимать, что те договоренности, по которым команда должна работать с беклогом проекта в Jira, выполняются максимально точно. Речь пойдет о чистой воды мониторинге и контроле, на который, к сожалению, не всегда хватает времени и желания.

Для внедрения подхода нужен хотя бы небольшой опыт работы с Confluence и поисковыми запросами в Jira (JQL), а также, собственно, наличие обоих продуктов — Confluence и Jira — в вашей корпоративной инфраструктуре. Без этого читать текст ниже нет смысла.

Мы будем идти по шагам — от проблем к их решению, постепенно улучшая это самое решение, получив нечто похожее на health-check мониторинг в Zabbix, где, нажав один раз F5, вы сможете получить сжатую и полезную информацию по проблемам в вашем беклоге или убедиться в их отсутствии.

Какие проблемы решаем

Рассмотрим несколько проблем, которые поможет решить подход, описанный ниже.

Исполнение договоренностей и правил, связанных с беклогом. Вы договорились с членами вашей команды, например, бизнес-аналитиками, ввести и использовать новое поле, отвечающее, скажем, за статус согласования требований с заказчиком — некий «Approval status».

Допустим, это кастомное поле имеет ряд значений и логика его использования отличается для различных состояний («Status») задач. Например, не должно быть ситуации, что «Story» уже сделана, а «Approval Status» = «Waiting for the customer’s decision».

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

Как за считанные секунды проверить, что то или иное поле используется командой корректно для нескольких сотен элементов беклога? А если таких полей много + есть их различные комбинации?

Заглядывание в историю. К великому счастью, Jira помнит о каждом переходе задачи из статуса в статус (поле «Status»), а также об изменении поля «FixVersion».

Как насчёт того, чтобы отслеживать те самые нехорошие переходы «справа-налево», в частности, отклоненные тестировщиками задачи и bug fix-ы? Или, например, несанкционированное изменение «FixVersion» для элемента беклога?

Проработка ситуаций, которые требуют внимания PM-а / Scrum Master-а. Было бы здорово иметь в одном месте несколько ссылочек на подборку «проблемных» элементов беклога, например, список багов, на фикс каждого из которых ушло больше 20 часов.

Есть JQL выборки, но что, если их много?

Те, кто знаком с расширенным поиском в Jira, знают, что все, что описано выше, можно получить, построив запросы с использованием встроенного в Jira языка запросов JQL. Освоить его не составляет труда — у Atlassian чудесная документация.

Например, вот часть реального запроса, который показывает элементы беклога, которые не должны быть взяты в работу без согласования с заказчиком через поле «Approval Status»:

project = XYZ AND («Approval Status» NOT IN («Tech auto-approved», Approved) OR «Approval Status» IS EMPTY) and type IN («Story», «Change request») AND Status != Open

Итак, вы напилили выборки, а теперь вопрос: что с ними делать? Почти все они не смогут отображаться так, как вам нужно в виджетах Jira.

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

Сохранить все выборки в виде фильтров и подписать на e-mail уведомления от Jira, если возвращаемые результаты изменились. Тоже вариант, но тоже так себе.

Пилим дашборд в Confluence

Можно выделить две группы проблем, которые мы хотим вскрыть с помощью JQL выборок:

• Что-то не должно случаться никогда. Как только случилось, вы должны узнать об этом и проблема должна быть устранена, например, через выставление правильного значения в каком-то поле. Выборка после этого должна возвращать 0 issues.
• Что-то может случаться время от времени. Вам просто нужно пойти и посмотреть, например, на тот самый баг, которые девелопер фиксил, влогав в него больше 20 часов. Вы каким-то образом отмечаете этот баг, и он тоже пропадает из вашего мониторинга.

Мы хотим, чтобы таких выборок было много, они покрывали практически все кейсы работы с беклогом, и мы, конечно, хотим, чтобы все они в идеале возвращали ноль или всего пару-тройку issues.

Приступим. Первые два шага:

1. Создаём новую страницу в Confluence.
2. Добавляем в нее таблицу на два столбца.
   
   • В первом пишем название нехорошей ситуации.
   • Во второй вставляем макрос {JIRA}с JQL запросом и со следующими настройками.

После этого накидываем еще различных выборок. Для беклога моего проекта с более чем 4,500 issues я использую 20 выборок. Некоторые из них содержат в себе по факту несколько логически связанных выборок, объединённых через OR. Получаем что-то такое:

Сохраняем. Получаем результат: что-то хорошо (0 issues), а что-то — требует внимания. Забегая наперёд, скажу, что я помечаю звёздочкой выборки, которые приходится обновлять после каждого релиза. Остальные — постоянные.

Теперь у нас есть страница в Confluence, обновив которую мы увидим, что хорошо, а что плохо. Ведь при обновлении страницы Confluence обратится к Jira и перестроит ссылки во втором столбце, предоставив нам актуальную картину.

Для ситуаций, которые неисправимы, например, всё те же баги в 20+ часами логов, я использую следующий подход:

• Добавляю к ним метку «checked_by_pm».
• Для того, чтобы такая задача ушла из выборки, я добавляю к выборке:

... AND (labels not in (checked_by_pm) OR labels is EMPTY)

Уже хорошо. В принципе можно здесь и остановиться, но можно ещё лучше.

Видеть только проблемы

Если мы исправили все наши проблемы, то нам не хотелось бы видеть 10...20 строк с «0 issues». Для того, чтобы их скрыть, понадобится недорогой, но чертовски практичный плагин Table Filter and Charts for Confluence. Он позволяет настроить таблицу так, что в режиме просмотра не будут отображаться строки с «0 issues», что позволяет значительно уменьшить место, которое занимает эта таблица.

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

Обратите внимание на filtration pane вверху таблицы

Как работать с этой таблицей

Мои рекомендации по этой специальной страничке простые:

• Пользоваться ею каждый день и исправлять нехорошие ситуации, о которых она сигнализирует.
• Постоянно расширять количество выборок. Ввели с командой новое правило или получили требование от руководства — новая выборка. Кто-то по любой причине нарушает договорённости — выборка. Нехороший тренд по какому-то из наборов issues — выборка.
• Сообщить коллегам об этой странице и смотреть на неё вместе каждую неделю на регулярных синках.
• Внедрить в вашу систему мониторинга. Я, к примеру, рядом с этой таблицей прямо в том же документе вывел виджет из Jira — workload команды, чтобы понимать загрузку команды. Также я поместил всё это рядом с дашбордом Zabbix-а, который связан с нашим продуктом в продакшене. Получился один экран, на котором есть вся необходимая мне оперативная информация.

Надеюсь, эта статья окажется вам полезной, а подход, как и мне, — сэкономит драгоценное время.

Буду рад услышать дельные комментарии и ваши решения подобных проблем.

У рубриці DOU Проекторвсі охочі можуть презентувати свій продукт (як стартап, так і ламповий pet-проект). Якщо вам є про що розповісти — запрошуємо взяти участь. Якщо ні — можливо, серія надихне на створення власного made in Ukraine продукту. Питання і заявки на участь надсилайте на editors@dou.ua.

Привіт, я Сергій, Java-програміст. Зацікавився написанням мобільних додатків у 2015 році. Це захоплення переросло у створення невеликої компанії з розробки ігор та додатків під назвою Headlezz. У цій статті піде мова про розробку, публікацію і просування мобільної гри-платформера Software Riot. Це гра про програміста, що має врятувати офіс від потужного комп’ютерного вірусу.

Перші кроки

Мій підхід у розробці полягав у отриманні досвіду та навчанні на власних помилках. На кожному своєму проекті я вивчав щось нове — нову технологію, способи монетизації, аналітики, маркетингу та ін.

Я писав додатки із використанням Apache Cordova, React Native, Android та Unity3D. Врешті-решт я зосередився на написанні саме мобільних ігор на платформі Unity3D. Причинами для вибору були доступність та величезна кількість туторіалів з написання ігор різного типу. Для монетизації я обрав банерну рекламу та rewarded-банери (перегляд рекламного відео для отримання бонусів).

Почав із простого жанру «2D-Runner», де персонаж постійно біжить, оминаючи перешкоди і збираючи бонуси. Я не планував витрачати багато часу на круту візуальну складову чи варіативність ігрової механіки, тому проекти були приречені. Проте одна із ігор таки змогла вийти в плюс, відбивши гроші на розробку і рекламу. Вона отримала 80K+ завантажень (Android+iOS) і принесла $460 прибутку. Але це інша історія. Якщо буде потреба, розкажу в іншій статті.

Отримавши певний досвід розробки і публікації проектів, я зміг зробити для себе такі висновки :

1. Ентузіазм швидко закінчується. Завдяки йому дуже просто створити прототип на хвилі емоцій, але, коли він завершується, довести проект до релізної версії — справжня мука. Із джерел в інтернеті я дізнався, що я такий не один, що у величезної більшості інді-розробників теж є фолдери із десятками недороблених проектів.

Цьому часто сприяє так званий «Shiny Object Syndrome» або ж «Синдром блискучого об’єкту». Він полягає у наступному: коли ти бачиш вдалині щось блискуче, ти відволікаєшся і йдеш до нього. Розгледівши предмет достатньо, бачиш вдалині інший блискучий предмет, і попередній для тебе вже не такий цікавий, і так далі. У світі програмування це надзвичайно актуально. Я певен, що багато девелоперів може підтвердити це кількістю своїх проектів на Гітхабі.

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

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

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

Ідея проекту

Отже, ми вирішили створити 2D-платформер, про який і йде мова у цій історії. Для сюжету ми (уже удвох із Дімою) обрали близьку для нас тему. Головний герой — це програміст, який має побороти комп’ютерний вірус, що захопив увесь офіс.

Назву гри, як і вигляд головного героя, ми визначили на основі голосування в нашій групі у VK (ще до його блокування).

Незначний відступ.У мене були спроби створення спільнот (VK, FB, Twitter, YouTube). Але одного разу я почув позицію американського інді-девелопера/блогера (Tim Ruswick) з приводу підтримання власного ком’юніті у соцмережах, з якою я повністю погодився. Звичайно ж, дуже добре мати розкручену спільноту — вона може дати вибух інсталів на початковому етапі гри. Проте розкрутка спільноти забирає надзвичайно багато часу, якого в мене не було.

Механіка нашої гри полягає у пересуванні поверхами офісної будівлі і маніпуляції з девайсами. За сюжетом комп’ютерний вірус захопив більшість девайсів, які загрожують герою смертельною небезпекою. Розбираючи безпечні девайси, можна створювати засоби боротьби з ворожою технікою.

У грі є дуже просте дерево навичок, яке розкриває нові засоби для боротьби з ворогами, а також — чат, у якому гравець спілкується з колегами для підказок.

Розробка

Проект Software Riot стартував у грудні 2016-гороку. З самого початку ми планували зробити 50 рівнів і встигнути зарелізити гру 1 березня 2017.

Почали із демосцени. Замовили у знайомої дизайн персонажа та базові покадрові анімаціїї (idle, біг, стрибок, смерть, розбірка девайсу, використання навичок). Також знайшли на стоках зображення офісних меблів та девайсів у «мультяшному» стилі. Сцена виглядала чудово, що дало нам непоганий поштовх у мотивації. Але вийшло так, що впродовж усього процесу розробки ми кілька разів додавали зміни до механіки, витрачали купу часу на виправлення. Тому навіть близько не встигли закінчити до зазначеної дати.

Наприклад, ми змінювали вплив деяких навичок (skills) персонажа на ворожі девайси, змінювали поведінку деяких девайсів. Через неправильне позиціонування елементів ми кілька разів перероблювали чат (для спілкування із другорядними персонажами) після тестування на сучасних девайсах з широкими екранами.

Спіймали чималу купу багів, пов’язаних із прокачкою навичок та діалогами в чаті.

Мені дуже заважав сором від «неідеального» вигляду проекту. Багато разів я розмірковував над тим, що ще рано випускати гру у світ. Через це ми кілька разів переробляли елементи, анімації, вигляд ігрових сцен. Наприклад, анімацію головного героя для фінальної сцени змінювали тричі повністю.

Дуже важливим для мене було відточення балансу у грі. Це стосувалося як рівнів (спочатку лінійний розвиток складності), так і планування кожної сцени для уникнення непрохідних ситуацій. Гравець має збирати деталі у рівнях, які накопичуються по мірі проходження. Довелося враховувати, що деякі гравці не будуть збирати деталі і можуть застрягнути без можливості пройти рівень.

Врешті-решт треба було знайти межу між «ідеалом» та шансом ніколи не випустити гру. Ми вирішили обмежитися 40 рівнями (спочатку планували 50) та лише англійською локалізацією у сподіванні, що близька до IT аудиторія сприйме це нормально. Замість 3 місяців ми витратили 19 і опублікувалися 18 липня 2018. Але краще пізно, ніж ніколи.

Фінансування на IndieGoGo

У процесі створення гри я задумався над можливістю фінансувати проект за допомогою краудфандинг-платформи IndieGoGo. Маючи в руках деморівень гри, ми записали промовідео, підготували матеріали та запустили кампанію.

В IndieGoGo є два типи встановлення цілі фінансування:

• Fixed — сума буде отримана автором тільки у випадку досягнення цілі; комісія системи — 5%.
• Flexible — сума буде виплачена у будь якому випадку; комісія складає 9% від суми. Чудово підходить для благодійних проектів.

Багато недосвідчених інді-розробників обирають 2-йваріант, адже в такому разі кошти обов’язково будуть виплачені. Але, як на мене, такі проекти не викликають особливої довіри у бекерів (людей, що фінансують проект).

Отже, я вирішив встановити flexible-ціль $2000. За моїми підрахунками така сума змогла б покрити витрати на розробку і маркетинг. Серед винагород для бекерів (perks) ми встановили:

• $2 — лист з подяками і wallpaper’ом (картинка для фону робочого столу) із головним героєм.
• $11 — листівка з символікою гри, підписана розробниками гри.
• $89 — бекер може дати ім’я пересічному персонажу у грі.
• $389 — преміум-спонсорство, яке включає внесення імені спонсора у титри, ігрові матеріали та навіть на нашу сторінку в магазині додатків.

Нагадаю, що попереднього досвіду краудфандингу я не мав, тому створював перки на власний розсуд. Я не мав бажання формувати довгий список винагород (чашки/футболки з символікою і т. д.), а ціни на існуючі перки встановлював виключно з метою таки зібрати цільову суму.

Ми запустили проект і просили кількох друзів в перші дні купити перки на власний розсуд — зібрали $70. Проект був оформлений непогано, на мій погляд, у порівнянні з конкурентами. Знаходився у топі кампаній IndieGoGo за запитам «mobile game» та «indie game», що врешті-решт вилилося у... нульзібраних коштів від аудиторії.

Висновки.Без бюджету на рекламу кампанії нічого не вийде. Єдине виключення — дійсно крута гра (механіка, графіка і т. д.). Тільки в цьому випадку можна сподіватися на «віральність» кампанії і мотивацію аудиторії інвестувати для появи гри у світ. Також перки повинні нести більшу цінність для юзерів, адже вони теж думають більше з точки зору власної вигоди, а не благодійності.

Публікація

У наших планах була публікація на Google Play та App Store, і Unity3D дозволяє з легкістю це зробити. Як це і роблять зазвичай, ми спочатку публікувалися у Google Play, тому що там значно легше вносити зміни в проект. У цей час за один тиждень ми пофіксили найприкріші баги і були готові до публікації для Apple-девайсів. Зараз ми маємо версії гри в обох магазинах додатків (Google Play, App Store).

Просування

Маю попередити, що методи просування і їх результати швидко змінюються. Я припускаю, що через рік після написання статті продуктивність деяких засобів впаде, що викличе появу інших або зростання популярності вже існуючих.

Для розкрутки гри ми використовували такі ресурси:

• огляди на Youtube;
• купівля трафіку для просування за ключовими словами;
• реклама AdWords;
• публікація статей на ігрових сайтах.

Останній пункт не приніс видимих успіхів, тому розповідати буду тільки про перші три.

Огляди на YouTube

YouTube вважається одним із найкращих варіантів для ігрового маркетингу через великий коефіцієнт інсталів та через відносно низьку їх ціну. Велику роль відіграє сама гра, адже, як би ютюбер не заохочував встановлювати «погану» гру, більшість людей обійде її стороною.

Маючи попередній досвід замовлення оглядів на YouTube, я вирішив рекламуватися у одного більш-менш великого оглядника ігор для Android (200 000+) та на каналі для iOS (70 000+). Незабаром я отримав листа від російського оглядача ігор на Android (300 000+) із досить щедрою пропозицією і вирішив спробувати.

Аудиторії усіх каналів — країни СНД. Для перевірки результатів використовував лінк-сервіси goo.gl, bit.ly, а також сторінки статистики у консолях магазинів додатків.

Замовлення і результати:

1. Android (200 000+). ТОП-10 ігор тижня — 7000 російських рублів (2900 грн).

Результат: ~ 150 переходів на сторінку (~ 70 installs). Найбільше розчарування. Причинами цього могли стати:

• специфічність аудиторії (звичка до високоякісного контенту);
• ТОП містив у собі мобільний порт для легендарної Fortnite, тому наша Software Riot могла залишитися майже непоміченою.

2. iOS. Персональний огляд + ТОП тижня — 4500 рублів (1900 грн)

Результат: ~ 70 завантажень.

3. Android (300 000+). ТОП-10 ігор тижня + Огляд + ТОП-20 ігор літа — 8000 рублів (3400 грн).

Результат: ~1900 переходів на сторінку, ~1100 завантажень. Найкращий результат. Перевищив усі сподівання.

Біржі трафіка

Існує кілька мереж, де можна купити інстали. Тобто паблішер створює замовлення на певну кількість інсталів, а аудиторія системи за невелику винагороду встановлює додаток на свій девайс. Такий трафік називається мотивованим.

Більшість таких систем пропонують додаткові послуги під час інсталу, а саме: 5-зірковийфідбек, повторні відкривання додатку через певну кількість днів, встановлення після пошуку за ключовим словом і т. д.

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

Я не став виключенням і використовую такий трафік для просування у лістингу за ключовими словам (результат помітив тільки для Google Play). Принцип такий: купуєш кілька встановлень за запитом «ключове слово», і через деякий час твій додаток піднімається у лістингу за таким запитом з позиції N на позицію N+M. Найцікавіше у цьому те, що, якщо купуєш дешевий пострадянський трафік за англомовними ключовими словами, це впливає на зростання позицій в усіх країнах.

У 2016 році я спромігся таким чином підняти свій баскетбольний додаток на перші позиції за цільовими запитами. Але, як уже було сказано, часи змінюються. Нещодавно я намагався вивести в ТОП інший баскетбольний додаток, але прогрес був майже непомітним.

Щодо гри Software Riot, я спробував мотивованим трафіком підняти позиції по ключовим словам Software і Riot, але це не дало плодів. Тому я зробив висновок, що усі якісні коливання у позиціях гри пов’язані із зростанням загальної кількості інсталів (від YouTube та реклами).

Реклама AdWords

За порадою товариша створив кампанію у AdWords для Android-версії. Це виявилося дуже простим завданням. Моєю метою було обрати аудиторію, близьку до IT-тематики, зі знанням англійської мови. І я вибрав... Індію! Якщо подумати, важко знайти більш підходящу країну.

Було встановлене обмеження у $5 на день. Загалом вартість 1 інсталу коштує 6 центів США (купівля мотивованого інсталу в СНД починається від 15 центів).

Висновок.На момент написання статті гру встановлено на 6700 Андроїд-девайсів та на 300 Apple-девайсів.

Монетизація

Як уже було сказано, основа монетизації Software Riot — реклама. Баннер показується на кожну третю смерть у грі. Також є вбудована відеореклама від Unity Ads, після перегляду якої користувач отримує у винагороду 30 деталей для крафту.

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

Результати за місяць:

• Android-версія: 16K показів реклами, CTR (click-through rate, відсоток кліків) 1.5%, прибуток — $7.37.
• iOS-версія: 500 показів, CTR 3.4%, прибуток — $1.50.

Unity Ads (з обох платформ) принесла $5.10.

Найбільша помилка

Фанати South Park мають пам’ятати серію про гномів, які викрадали спідню білизну. На питання, нащо вони це роблять, гноми ознайомили героїв зі своїм 3-фазнимпланом:

• Phase 1 — Collect underpants.
• Phase 2 — ?
• Phase 3 — Profit.

Дуже прикро, що у гонитві за ідеєю проекту та публікацією, я не вирахував прибутковості. У глибині душі я розумів, що з такою кількістю ігрового часу важко розраховувати на пристойний прибуток на рекламі. Але надавши перевагу отриманню досвіду створення цікавої гри, ми знехтували прибутковістю.

Трішечки теорії.Існує дуже проста формула для підрахунку прибутковості проекту: середня вартість залучення нового користувача (Acquisition Cost) ділиться на середній прибуток за час використання додатку користувачем (Lifetime value).

Lifetime value у нашій грі менше 1 центу. Це означає, що, скоріш за все, єдиними рятівними варіантами для нас можуть стати:

• органічний пошук, який буде приносити постійний трафік;
• віральність, яка рідко залежить від розробників і часто буває абсолютно спонтанною.

Висновки

Отож, за 19 місяців ми розробили і опублікували гру. Особисто мені вона обійшлася у трохи більше ніж у 100 000 грн. Не найдешевше хобі... Я сподіваюся, мій досвід допоможе молодим інді-розробникам уникнути проблем, які трапилися на моєму шляху.

Незважаючи на те, що у моєму списку є лише одна прибуткова гра (я про неї згадував раніше), насмілюся таки дати кілька порад:

• Беріться тільки за ті проекти, які ви точно зможете зробити за відносно короткий проміжок часу, і дороблюйте їх.
• Якщо ви маєте за мету заробити гроші, то порахуйте, як саме (і чи можливо це взагалі).
• Без маркетингу і реклами вам не стати другим Flappy Bird. Яку б чудову гру ви не написали, юзери про неї самі не дізнаються.
• Що б не сталося — не шкодуйте того, що вже не виправити. Отримуйте досвід і йдіть далі.

Про спільноту українських інді-розробників

Звичайно ж Україна має спільноту інді-розробників, зосереджену у соцмережах. Є група на Фейсбуці Game Developers — Ukraine (11К+).

Також жителям Києва пропоную відвідувати Kyiv Indies Meetup. Це — щомісячна зустріч інді-розробників, на якій можна почути виступи видатних фігур Indie Game Dev індустрії.

От редакции: в рубрике DOU Booksучастники сообщества рассказывают о пяти любимых книгах — тех, которые меняют мировоззрение и могут быть полезны читателям-коллегам.

[Василий Ульянов — сооснователь Genesis. Более 10 лет в IT и инвестиционной отрасли. Занимается международным развитием компании, увлекается плаванием и спортивным бриджем]

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

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

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

Бен Хоровиц «Легко не будет. Как построить бизнес, когда вопросов больше, чем ответов»

В оригинале — Ben Horowitz «The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers»

В украинском переводе — Бен Горовіц «Безжальна правда про нещадний бізнес»

Первый надрыв — это опасные моменты в бизнесе, форс-мажоры, угрозы банкротства, физической безопасности. Фантастическое обезболивающее — это книга Бена Хоровица.

Ее можно назвать настольным пособием CEO, так как она включает в себя рекомендации и по оперативному, и по стратегическому управлению. По сути, это один большой кейс с описанием карьеры самого автора. Бен Хоровиц начинал как рядовой программист в компании SGI, потом работал в Netscape, потом в AOL и далее ещё в десятке-другом известнейших IT-компаний. При этом он прошёл путь от рядового сотрудника до управляющего (CEO) и учредителя, а в настоящее время управляет инвестиционным фондом. Это означает, что современный IT-бизнес он знает вдоль, и поперек, и сверху донизу.

Вот пара цитат оттуда:

«Борьба — это ваш желудок, сжимающийся так сильно, что вы, кажется, вот-вот начнете харкать кровью».

«Любой великий предприниматель, от Стива Джобса до Марка Цукер­берга, прошел через борьбу и выдержал это — так что вы не одиноки. Но это не значит, что и вы выдержите. Возможно, вас ждет провал. Потому это и называется борьбой. Именно в борьбе рождается величие».

Гэвин Кеннеди «Договориться можно обо всем! Как добиваться максимума в любых переговорах»

В оригинале — Gavin Kennedy «Everything Is Negotiable: How to Get the Best Deal Every Time»

В украинском переводе — Гевін Кеннеді «Домовлятися завжди. Як досягати максимуму в будь-яких перемовинах»

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

Огромное количество мудрости и практических советов собрано в книге Гэвина Кеннеди. Я рекомендую перечитывать эту книгу 1 раз в месяц, пока не зазубрите ее.

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

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

Несколько полезных мыслей:

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

Рэнди Стрит, Джефф Смарт «Кто? Решите вашу проблему номер 1»

В оригинале — Geoff Smart, Randy Street «Who: The A Method for Hiring»

Боль номер три — окружить себя правильными людьми. Более половины браков в нашей стране заканчиваются разводами. Плюс еще 25-30%пар из оставшихся наверняка живут как в аду. То есть даже в таком серьезном вопросе, как выбор спутника жизни, 80% людей совершают ошибки. А поскольку коллег, как правило, выбирают не так тщательно, как жену, выводы напрашиваются сами.

Никогда не работайте с мудаками и научитесь увольнять. «Who: The A Method for Hiring» — вот рецепт. Выучите эту книгу наизусть, каждый год пишите саммари по ней. Интерпретация одних и тех же тезисов будет отличаться по мере роста вашей зрелости.

Рэй Далио «Принципы. Жизнь и работа»

В оригинале — Ray Dalio «Principles: Life and Work»

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

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

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

Очень часто в биографических книгах не хватает четких советов, а практические написаны теоретиками. Но «Принципы» совмещают в себе историю успешного практика и конкретные советы.

YouTube-каналдоктора биологических наук Сергея Савельева

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

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

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

В рубрике DOU Labsмы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

Привет. Меня зовут Евгений Моспан, работаю Solution Architect в компании EPAM. Сегодня я хочу рассказать о проекте под названием EPAM Delivery Platform, целью которого — минимизировать время для построения на проекте эффективных CI/CD практик.

Идея проекта

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

В EPAM одной из таких инициатив стал наш проект под названием EPAM Delivery Platform (далее по тексту сокращенно EDP). Сама идея возникла в конце 2017 года. Основная задача EDP — обеспечить минимальное время для так называемого спринта 0, когда и происходит формирование основных практик на проекте, конфигурирование CI/CD и другие процессы. После этого приступить в спринте 1 к разработке бизнес-фич, которые можно демонстрировать заказчику, автоматизировано тестировать и пропускать через конфигурируемые Quality Gates на различных этапах CI/CD процесса.

Цель EDP:сделать длительность спринта 0 — максимум в 2 недели, которые включают в себя разворачивание инфраструктуры, настройку CI/CD под конкретный проект, обучение команды тем инструментам и pipelines, которые используются в решении.

Команда:в ней собраны архитекторы и инженеры (software engineers, DevOps, testing engineers), которые имеют достаточно глубокую экспертизу и опыт разработки проектов на Java, JavaScript, .NET с использованием современных CI/CD практик.

Девиз:«Business value from Sprint 1».

Основные технологии, выбранные для проекта

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

Основные технологии EDP:

• Контейнеризация на основе Docker.
• Оркестрирование контейнеров посредством Kubernetes.
• Platform as a Service поверх Kubernetes — OpenShift.

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

Опытные пользователи OpenShift или Kubernetes заметят, что существует немало уже готовых решений или референсных статей, таких как:

• CI/CD with OpenShift;
• Continuous Integration and Continuous Delivery with Fabric8;
• OpenShift.io;
• И, например, очень свежее решение на основе Kubernetes и Istio.

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

Команда Fabric8, с другой стороны, проделала огромный, я бы даже сказал титанический объем работы по адаптации Java-приложений на базе Spring Cloud + Netflix, обещая возможность деплоймента микросервисных решений как в OpenShift, так и в Kubernetes. К слову, именно этот продукт оказал наибольшее влияние на архитектуру и возможности EDP.

В тоже время с точки зрения конечного пользователя Fabric8 не выглядит легким в применении. Анализируя возможности Fabric8, команда EDP даже шутила, что это the most bleeding cutting edge they’ve ever seen. Причиной этому была банальная невозможность проинсталлировать стабильную версию платформы, будь то на minikube/minishift или полноценные кластеры OpenShift и Kubernetes. Возможно, это связано с тем, что судя по саммитам Red Hat (например, это видео) команда разработчиков Fabric8 помогает строить OpenShift.io, что повлекло за собой снижение темпов разработки самого Fabric8.

OpenShift.io выглядит очень многообещающей платформой, в которой, однако, есть пару важных «но»:

• Интегрированная система управления проектом значительно уступает привычным Jira, Rally, Trello и т. д. Многие ли захотят использовать новый инструмент с отсутствием уже привычного функционала?
• Разработка в браузере на основе Eclipse Che выглядит очень привлекательно с точки зрения менеджера и Ops, но мне сложно представить там радостно работающих senior developers, привыкших к взрослым полнофункциональным IDE.

OpenShift.io заслуживает более детального изучения и отдельной статьи. Как, впрочем и новая восходящая звезда — KNative. Говорить много об этой технологии пока рано, посмотрим, насколько далеко они смогут зайти. Начало выглядит многообещающим.

Из чего состоит и как работает EPAM Delivery Platform

Для дальнейшего рассказа об архитектуре и пользе EDP для стартующих проектов в EPAM, стоит сразу описать ее основные функции:

• Интегрированный набор инструментов для организации CI/CD, с возможностью заменять инструменты аналогами.
• Централизованная система аутентификации и авторизации. Организация SSO для всех CI/CD инструментов и интеграция с корпоративным SSO. RBAC-контроль доступа к ресурсам платформы.
• Прозрачная интеграция source code приложений в CI/CD инструменты.
• Конфигурируемый continuous delivery pipeline с возможностью настройки последовательности его этапов (stages).
• Обеспечение автоматизированного тестирования (functional, security, performance etc) каждого из этапов CD pipeline, а также конфигурация и контроль quality gates для каждого из них.
• Мониторинг кластера для разработки и централизованный сбор логов.

Архитектура EDP представляет из себя набор взаимосвязанных абстрактных компонентов и API для них. С их помощью имплементируются основные функции платформы. Компоненты можно разбить на 3 крупных логических блока:

• Инструменты для организации CI/CD.
• Компоненты для запуска автоматизированных тестов.
• Continuous delivery pipeline, состоящая из произвольного набора stage. В их рамках производится запуск автоматизированных тестов и контроль прохождения посредством анализа quality gates.

Список инструментов для организации CI/CD, их назначение и поддерживаемые имплементации представлены в таблице ниже:

Диаграмма ниже представляет собой логический дизайн EDP на базе описанного выше набора инструментов:

Как видно из таблицы и диаграммы выше, EDP опирается на известные и широко применяемые opensource инструменты, посредством которых обычно строят CI/CD на большинстве проектов. Основной added value EDP — это стандартизация API по интеграции и взаимодействие этих инструментов как во время инсталляции платформы, так и при ее использовании. Основная цель — предоставление точек расширения для пользователей EDP и возможности замены компонентов, которые входят в платформу. Рассмотрим более конкретные примеры. Как уже было сказано выше, EDP выделяет два основных вида API:

• Integration.Каждый инструмент необходимо установить в платформу, сконфигурировать, интегрировать в SSO. Поэтому базовые функции такие:
  
  • install()
  • configure()
  • integrateWithSSO()
  Более специфичным является интеграция инструментов между собой для обеспечения заявленных функций EDP. Например, для СodeAnalyzer можно выделить такие:
  
  • uploadEdpQualityProfiles()
  • registerCIServerFunctionalUser()
• Runtime.После установки платформы пользователи могут добавлять свои приложения и конфигурировать для них CD pipeline. Эти возможности составляют вторую часть API, которую EDP предоставляет для описанных инструментов. Из наиболее понятных примеров можно привести следующие:
  
  • CodeReview:
    
    • registerNewApplication(), который позволяет зарегистрировать новое приложение и осуществлять процесс code review.
  • CICDServer:
    
    • registerFeatureBranchPipeline(), который обеспечивает добавление CI pipeline для запуска на каждый commit в feature branch.
    • registerPullRequestPipeline()регистрирует pipeline для каждого добавленного приложения, который отвечает за его сборку после подтверждения pull request.
    • addStageToPipeline()позволяет добавить новый stage в CD pipeline, обеспечивая механизм автоматического промоушена между stage.

  Схематично компоненты EDP и их API можно представить в виде следующей high-level диаграммы:

  Выше была затронута тема CI/CD pipeline, рекомендуемую EDP, которую можно представить следующим образом:

  Как видим, EDP выделяет два основных этапа для CI:

  • интеграция и проверка кода, который создаётся в feature branch;
  • интеграция, проверка и сборка кода после сабмита pull request.

  EDP поддерживает возможность не только интеграции кода на двух описанных выше этапах, но и их установки на временные environments. Последние доступны либо конкретному разработчику, либо команде. Стоит отметить, что такой подход к разработке может оказаться достаточно ресурсоемким с точки зрения инфраструктуры. Поэтому рекомендацией по умолчанию от EDP является использование ограниченного количества environment, куда производится deploy последних версий приложений и осуществляется контроль их качества. С одной стороны, это экономит ресурсы инфраструктуры с другой стороны — уменьшает так называемый «integration hell». По умолчанию EDP рекомендует следующий набор shared environment для основной ветки разработки:

  Где

  • SIT — System Integration testing — этап, на котором рекомендуется запуск автоматизированных тестов.
  • QA — Quality Assurance — этап, на котором осуществляется верификация новой функциональности разрабатываемых приложений.
  • UAT — User Acceptance testing — этап для демонстрации приложения конечным пользователям и предоставление им возможности самостоятельно поработать с новой функциональностью.

  Для каждого из этапов осуществляется deployment всех приложений на выделенный environment. После успешного deployment осуществляется запуск автоматизированных тестов, настроенных для этого этапа и контроль quality gates. Схематично pipeline можно представить в виде следующих высокоуровневых шагов:

  Отдельного внимания заслуживает EDP Cockpit, который представляет из себя web-интерфейс для Runtime API EDP. Cockpit позволяет осуществлять добавление новых приложений, конфигурировать последовательность этапов для CD pipeline, определять, какие автоматизированные тесты запускать на том или ином этапе и т. д. Работа с Cockpit начинается с прохождения wizard, который позволяет настроить EDP под конкретные нужды:

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

  Завершается работа wizard конфигурированием CI/CD Pipeline:

  Давайте подытожим, что же получает пользователь EDP после установки в OpenShift кластер:

  • Интегрированный набор CI/CD инструментов с настроенным SSO, централизованной аутентификацией и авторизацией. Это облегчает доступ конечных пользователей к ресурсам платформы и позволяет гибко контролировать уровень этого доступа.
  • Исходный код EDP с возможностью его кастомизации под нужды проектов.
  • Быстро добавлять исходный код приложений и проекты с автоматизированными теста посредством Cockpit.
  • Настраивать CD pipeline, управлять набором автоматизированных тестов, запускаемых на каждом этапе, а также назначать quality gates для обеспечения контроля качества.
  • Инструменты для централизованного сбора логов и мониторинга.

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

  Что сейчас и что дальше

  EDP сейчас уже не просто внутренняя инициатива EPAM. Теперь это платформа, на которой имплементировано несколько проектов и начинаются новые. Один из них предполагает размер команды до 100 человек с различной экспертизой, что повышает уровень сложности и ответственности настройки платформы. AWS и Azure являются Cloud Provider для этих проектов, а потому команды EDP получают важный опыт по управлению кластерами OpenShift в public cloud в соответствии с последними рекомендациями Red Hat.

  Естественно, команда EDP не планирует останавливаться на достигнутом. Наши следующие шаги:

  • Добавление новых инструментов, которые реализуют API компонентов EDP.
  • Более тонкая настройка pipeline на этапе их добавления.
  • Расширение списка поддерживаемых технологий для разработки и framework.
  • Более тесная интеграция c managed services of public clouds.
  • Развитие инфраструктуры и конфигурации кластера OpenShift для соответствия самым строгим security стандартам.
  • Интеграция серверов для хранения и анализа результатов performance и security тестирования и многое другое.

  Важным моментом развития EDP является внедрение этой платформы для проектов, которые разрабатываются в рамках EPAM RD (Resource Development). Это позволяет молодым специалистам сразу привыкать к самым высоким стандартам разработки кода на современных проектах.

  Спасибо вам за внимание и прочтение данной статьи. На возникшие вопросы по мере сил постараюсь ответить в комментариях :)

Статья создана в соавторстве с Danil Kuhta.

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

Коротко о поиске локаций

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

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

Google-решению есть и альтернативы, такие как:

• HERE Places API;
• Yelp businesses search;
• Foursquare Places API.

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

Предварительная обработка запроса

Чтобы система выдавала более качественные результаты, сам поисковый запрос нужно предварительно обработать — очистить от лишних адресных составляющих. У Android для этого есть встроенный «Геокодер» (Geocoder), который способен обрабатывать прямое и обратное геокодирование, а это, в свою очередь, помогает выстроить алгоритм удаления тех самых лишних компонентов из каждого поискового запроса.

Геокодер работает по следующему принципу: составляется список адресов для каждого поискового запроса, в котором этот запрос сравнивается с каждой составляющей адреса. Таким образом, лишние составляющие легко удаляются.

Магия искусственного интеллекта

Так почему Google выдает результаты лучше других? Как он обрабатывает запрос? Разработчики Google в свой поисковик встроили собственный алгоритм искусственного интеллекта (ИИ), который помогает выдавать нужные пользователю результаты.

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

Как этого можно достичь в контексте поиска мест: задача «Hello, world!», в Machine Learning — ответить на вопрос «Какое число нарисовано на картинке?», а возможные ответы — цифры «0, 1, 2... 9». В качестве входного параметра используется картинка.

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

Как применить ИИ для поиска мест

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

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

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

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

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

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

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

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

Поисковый запрос может содержать и дополнительную локацию для поиска в виде адресного компонента (населённый пункт, название улицы, полный адрес), которая аналогично поддается сравнению. Рейтинг места и уровень цен точно так же важны и вполне сопоставимы.

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

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

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

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

Практическая реализация

Попыток претворить в жизнь нашу идею было несколько. Первый раз было принято решение использовать библиотеку FANN (Fast Artificial Neural Network — быстрая искусственная нейронная сеть). Она имеет открытый исходный код и позволяет применять многослойные искусственные нейросети в C.

Главные особенности библиотеки состоят в следующем:

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

Во второй раз мы использовали TensorFlow. Среди его преимуществ:

• быстрая работа, для обработки можно использовать GPU;
• есть вся документация, написана доступно и понятно;
• есть инструменты для визуализации.

Первая нейросеть

Для начала мы интегрировали библиотеку FANN в приложение Android с помощью NDK.

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

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

Проверялось обучение так: все собранные данные делились на две части, в пропорции 70% / 30%, где 70% было отведено под само обучение, а оставшиеся 30% — уже на проверку. Для наочного отображения результатов после каждого этапа рассчитывался параметр, который показывал процент правильных ответов из набора проверочных данных.

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

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

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

Вторая нейросеть

Здесь реализацию проекта мы поделили на две части.

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

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

В результате мы получили 93-94%правильных ответов.

Динамика изменения настроек

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

В Таблице № 1 представлены результаты обучения сети путем изменения вводимых параметров:

Таблица № 1

Что касается тех входных данных, которые использовались для сравнения строк, в Таблице № 2 можно проследить динамику изменения показателя правильных ответов после добавления дополнительных параметров.

Таблица № 2

Стоит отметить, что параметры «полное совпадение с запросом» и «количество совпадающих слов» по отдельности давали результаты хуже, чем в паре.

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

Хочется также упомянуть, что никаких специфических правил для настройки и обучения «классической» нейронной сети не существует. Это решается только эмпирическим путем.

Выводы

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

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

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

P. S. Дополнительный бонус нейросети — простой код бережет нервы программисту :)

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

Image Source: ismaeloo 4

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

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

О техниках и способах повысить личную эффективность

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

Определите свои цели

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

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

Не начинайте день без плана

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

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

Распределяйте задачи по приоритетности

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

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

ABCD

А — обозначает задачи, остро нуждающиеся в выполнении именно сейчас. Если такие задания не завершены вовремя, то будут неприятные последствия. Если всё сделано в срок — положительный исход. Когда таких задач несколько, используйте цифры: А-1, А-2, А-3.

B — также обозначает обязательные задачи, но к ним вы приступаете после А-приоритетных. Они менее срочны и не влекут за собой таких опасных последствий, однако их выполнение для вас важно. То есть В — это всё то, что необходимо сделать, но нет кризисного «прямо сейчас».

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

D — задачи, которые можно делегировать другому человеку. Если у вас есть такая возможность и вы можете положиться на другого человека, то эти задания стоит отдать на условный аутсорс.

Метод Айви Ли

1. В конце каждого рабочего дня запишите пять самых важных вещей, которые вам нужно выполнить завтра. Не записывайте более шести задач.
2. Расставьте по приоритетам эти шесть пунктов в порядке их истинной важности.
3. Когда вы приедете завтра на работу, сконцентрируйтесь только на первой задаче. Работайте до завершения первой задачи, прежде чем перейти ко второй задаче.
4. Подходите к остальной части своего списка тем же способом. В конце дня переместите незавершенные дела в новый список из пяти задач на следующий день.
5. Повторяйте этот процесс каждый рабочий день.

Делите, делите и ещё раз делите

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

Концентрируйтесь только на одной задачи

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

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

Создайте рабочую атмосферу

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

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

Применяйте закон 80/20

Всеми любимое и очень известное правило Парето всё ещё актуально. Объясню его суть на примере:

20% времени, затраченного на планирование архитектуры, сохраняет 80% времени при разработке.

20% производимых услуг приносит 80% прибыли.

20% выполняемой работы приносит 80% результата.

Остается лишь правильно определить те самые наиболее эффективные 20% и уделять особое внимание именно им.

Понимайте конечный результат

Вернемся к моменту, когда вы определились со своей целью. Мало того, что она должна у вас быть, так ещё и важно иметь представление о ней. Чем более оно красочное и живое — тем с большей вероятностью ваши действия приведут к поставленной цели.

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

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

Трекинг работы и её производных

Есть море программ, направленных на то, чтобы люди могли следить за своим временем, куда оно уходит и в каких объемах. Я до сих пор не особо верю, когда слышу: «У меня нет времени». А что самое ироничное — говорят это вполне себе свободные личности. Время есть всегда, и вопрос лишь в том, готовы ли вы жертвовать им во благо чего-то. Можете ли вы отказаться от сериала на ночь, чтобы улучшить свой сон? Готовы ли вы проводить меньше времени с друзьями, чтобы больше работать? За всё нужно расплачиваться.

Если вы трекерите своё время, то вы четко понимаете, куда оно уходит. Проанализировать, на что вы тратите больше всего часов, призваны следующие программы: RescueTime (есть для компьютера, браузера, телефона и персидского кота), PhoneUsage (мобильные платформы) и т. п. Они присылают вам отчётность, где сколько времени вы провели, а уже из этих данных вы можете сделать много интересных выводов.

Думайте на бумаге

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

Что думают о тайм-менеджменте IT-специалисты

Игорь Ткач, CTO в Daxx

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

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

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

Для краткосрочных задач я веду «to do»-списки. Что касается целей средней и дальней перспективы (месяцы-годы), для их планирования использую Trello-доску. Она состоит из колонок «Ideas», «To do», «In progress», «Done», «Postponed», где задачи отсортированы по приоритету, которые я определяю с помощью матрицы Эйзенхауэра и некоторыми элементами методики Getting Things Done.
Также, помимо всего, неделя и каждый день планируются с помощью календаря. Спустя время уже выработалась привычка следовать установленному расписанию, поэтому всегда держу его в актуальном состоянии.

Для предотвращения накопления мелких задач использую так называемое «правило двух минут». Если есть мелкая задача, выполнение которой займет не более 2-5минут (ответить на важный имейл, например), проще выполнить ее тут же, не откладывая. Важно отметить, что бывают исключения. Это правило не действует в моменты, когда вы находитесь в состоянии потока. Фокус очень важен, и потому я стараюсь работать только над одной задачей в каждый момент времени. Исходя из этого, нередко бывает такое, что самое сложное на первых этапах — умение сказать «нет» менее приоритетным задачам и запросам.

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

Андрей Момоток, UX/UI Designer, Freelance

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

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

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

Виталий Марусяк, Project Manager в Provectus

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

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

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

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

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

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

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

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

Мабуть, я не відкрию великої таємниці, якщо скажу: коли вам обіцяють, що проект простий і ви тихенько зробите його за три місяці, не вірте. Краще множте терміни у 3-5 разів.Запасайте декалітри кави. Набирайтесь терпіння. Готуйтеся до пригод із документацією. Якщо обіцянки справдяться, то раніше відпочинете. А як ні — будете морально загартовані.

Отже, я працюю System Architect у EPAM Ukraine. Нещодавно ми успішно завершили проект з digital transformation однієї голландської компанії. Як ви вже, певно, здогадалися з попереднього абзацу, «успішно» не означає «просто». Розкажу, як ми допомогали трансформувати бізнес і міксували DevOps best practices з мистецтвом комунікацій.

Передісторія

Наш замовник — B2B-постачальник повнофункціональних метеорологічних рішень. Простіше кажучи, вони продають опрацьовані метеорологічні дані, в тому числі у вигляді гарних картинок, які ми потім дивимося у прогнозах на ТБ.

Спочатку було три різні компанії у трьох різних країнах. Потім голландці забрали дві інші під своє крило. І вже тоді встигли створити собі задачку на майбутнє. Головна компанія не стала перебудовувати інфраструктуру своїх надбань і залишила її, як є. Так само, як і людей. Новоутворений холдинг став схожий на клаптикову ковдру, де кожен шматок займався чимось своїм, а з іншими скріплявся грубими стібками. Через це, звичайно, виникало багато проблем із міграцією даних. Зокрема, з тією швейцарською компанією, яка згодом потрапила до нас у вигляді проекту.

Система підрозділу, який відповідав за збір метеорологічних даних, дуже складна. У їхню інфраструктуру потрапляють необроблені дані відразу з п’яти потоків. А три різні бази даних інфраструктури, до прикладу, були підключені до одного програмного забезпечення, яке в свою чергу підключене до іншого.

Дата-центр підрозділу обробляє сирі дані та розподіляє їх на два окремих продукти: дані з малюнками та анімацією, що продаються клієнтам, та відео із прогнозом погоди. А ще ж є показники, які отримують із супутників та метеорологічних станцій.

Справа в тому, що навіть після юридичного об’єднання ця підкомпанія продовжувала жити своїм життям. Вони розміщували інфраструктуру в дата-центрі буквально навпроти офісу, причому за шалені гроші. Тільки ISP коштував компанії сотні тисяч євро. А щомісячна плата складала десятки тисяч євро плюс додаткові витрати на його підтримку.

Життя новоутворених холдингів бентежне, але бізнес є бізнес. І наш майбутній замовник вирішив, що хоче не просто продавати метеорологічні дані, а створювати круті продукти на їхній основі. Наприклад, уточнювати та гіперлокалізувати прогнози до масштабу майже 2 на 2 км. Але перш ніж братися за інновації, необхідно було укріпити тили і навести лад у back-end. Для цього CTO замовника запустив програму Cost Saving. Її мета — через вихід у хмару відмовитися від інфраструктури, розкиданої по різних дата-центрах і зекономити кількасот тисяч доларів на рік. Причому то мав бути не лише перенос, а і грамотна оптимізація. Із цією задачкою вони прийшли в EPAM.

Неприємні сюрпризи

Проект потрапив до мене як терміновий. З клієнтом уже були попередні домовленості, залишалося розставити крапки над «і» та починати працювати.

Спочатку на проект виділили три місяці. Я поїхав до замовника, і його CTO відразу мене заспокоїв: «Не переживай, у нас кейс простий. Є дорогий дата-центр у Швейцарії, і нам треба швиденько перенести все, що там є, у клауд і таким чином зрізати кости». Він називав це «shift & lift». Я зрадів, але сказав: «Давайте подивимось». І почав дивитися.

Тут почалися сюрпризи.

З невідомих нам причин стейкхолдери почали залишати швейцарський дата-центр, у якому вони працювали і в якому утримувався шматок компанії. Пішов і CTO, замість нього взяли нову людину, яка тільки переймала справи. Переносити інфраструктуру без тестування було неможливо. Обіцяний «shift & lift» залишився у моїх мріях — людей, які могли щось розповісти, ставало все менше. До того ж нас чекав цілий букет із старого заліза, legacy-систем та рішень.

Оцінивши ситуацію, я зрозумів, що в три місяці ми не вкладемося. Зібрав команду із 7 людей. Ми по маленьких шматочках почали збирати інформацію щодо організації інфраструктури і вибудували часткову структуру. Але зіштовхнулися з однією великою проблемою — монолітністю: варто відключити один сервіс, помирають усі інші.

Щоб зрозуміти, що коїться із сервісами, необхідно було зрозуміти, звідки почати. Ми довго крутилися, зняли снепшоти з усіх існуючих машин, намагалися збагнути, що і як працює всередині, але даремно. Люди, які могли щось пояснити, то звільнялися, то йшли у відпустку або мало відповідали.

Ми зрозуміли, що чекати допомоги немає звідки. Треба було робити повний реверс інжиніринг.

Пробиваючи стіни

Через людський фактор ми мали найбільше веселощів. Так як у компанії офіційно оголосили digital transformation, у якому наш проект брав участь, люди думали, что їх просто звільнять після закінчення. І хоча насправді це було не так, ми скрізь натрапляли на «лежачих поліцейських».

У клієнта дуже багато всілякого legacy staff, який вони так і не мігрували у хмару та не автоматизували. Команда, яка займається data flow і сидить на всіх цих legacy, прекрасно розуміла, що ми можемо автоматизувати все, що вони нині роблять руками. І вони стануть просто не потрібні. Хоча в нас і в планах такого не було.

З командою operations виникали інші нюанси. Там є люди, які працюють багато років. І вони не дуже хотіли переїжджати на новий стек технологій Amazon, бо не особливо з ним знайомі. У них у дата-центрі кілька машин працювало на старому Oracle, і перемігрувати його на Amazon повністю вони не захотіли. Мовляв, хай буде, як є. Причина — «тому що ні».

Такий супротив ми зустрічали практично в кожному департаменті, поки не показували, як після міграції все автоматично працює. Врешті-решт, з усіма структурами це допомогло.

Інша причина — був окремий вендор, який займався виключно підтримкою Oracle. Замовник передав їм інструкцію, що необхідно зробити, щоб перенести Oracle. А фактично все зробили ми: підготували машину, засетапили, зробили в Amazon усі правила. Єдине, що зробили люди вендора — інсталювали Oracle и перенесли туди дані. На листування із вендором з поясненнями та переконаннями ми витратили в цілому близько чотирьох місяців.

Останню стінку ми пробивали лобом уже безпосередньо перед закінченням проекту, коли його треба було продовжити, щоб нормально закінчити та передати. Для цього нам дали ще одну частину інфраструктури. Це називалося broadcasting — коли картинки накладаються шарами один на інший, і завдяки даним повністю вимальовується прогноз погоди. На цьому етапі проект виглядав безхмарним, а ми були налаштовані оптимістично. Проблем ми не очікували, адже спілкувалися із knowledge keeper, який охоче ділився інформацією та обіцяв невдовзі передати всі необхідні дані.

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

Смішно, але тут ми знову зустрілися з вендором по Oracle. Незважаючи на те, що один раз ми їх уже «перемогли», історія повторилася. Уявіть собі e-mail thread на 4-5моніторів (у згорнутому виді). Отакий у нас був діалог по маленькій справі. Але ми люди терплячі, розуміли, що працюємо з різними людьми. І повільно, але впевнено все це рухали.

3 -> 6 -> 15

Ми поділили команду на шари: хтось займається скриптами, хтось — даними, хтось — потоками. Щоб покрити ризики всередині хоча б нашої команди, ми робили свої внутрішні сесії, де ділилися один з одним, хто що знає, як що працює. І все документували. Це допомогло підстраховувати один одного, коли хтось ішов у відпустку або був відсутній за сімейними обставинами.

Урешті-решт, ми знайшли, куди йдуть дані, і з цієї ниточки почали «розслідування». Оскільки компанія заробляє на постачанні консолідованих і оброблених даних, наша команда розбиралася саме з data flow. На цьому етапі було дуже важливо показати клієнту, що в нас є експертиза, що ми можемо з цим розібратися (до речі, за рахунок досвіду команда наша була в два рази менше, ніж та, яку зазвичай будують на таких проектах).

Коли ми повністю розібрали топологію мережі і те, що коїться в їхньому швейцарському дата-центрі, клієнт нам повірив.

Я одразу говорив, що це не буде просто і забере мінімум рік. Завжди давав апдейти, ходив на transformation-мітинги до клієнта. Розповідав усе, як є. Тому нам подовжували проект. Початковий контракт збільшили до півроку, а потім одразу ще на півроку.

Технології

Для Infrastructure-as-a-Code ми використовували SparkIFormation, для automated provisioning (CM) — Puppet, тому що він уже був присутній, але працював лише для створення юзерів і не був допрацьований у тому масштабі, щоб його можна було використовувати повноцінно.

Для моніторингу ми використовували Icinga. Для трекання карток беклогів — Trello плюс Confluence для зберігання даних та knowledge transfer. Для деплойментів — Jenkins та Bamboo. Бази даних у них були MySQL, ми перенесли їх в Amazon RDS. Також був Oracle, який ми теж перенесли та автоматизували (не без пригод, як я згадував трохи вище).

Результати

Проект закінчено у серпні. Ми переключили все на структуру Amazon. Повністю автоматизували все в DevOps best practices. Зробили повний reverse engineering до рівня бібліотек. Перемістили та перейшли на AWS, впровадили сучасний технологічний потік, зменшили ризики інфраструктури. Зробили так, як початково і хотів замовник: однією кнопкою все (або частина інфраструктури) піднімається та опускається. Ми залишили Disaster recovery plan, все задокументували і зробили knowledge transfer сесії.

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

У цьому проекті величезну роль відіграла вся наша команда. І те, що ми всі разом працювали як один злагоджений механізм, дало нам можливість досягнути результатів, про які я зараз розповідаю. Не відкрию велику таємницю, коли скажу, що над командою теж треба працювати — створювати комфортні умови, ділитися знаннями, давати повне розуміння ситуації та підтримувати і мотивувати. Те ж саме треба вибудовувати і в стосунках із клієнтом. У нашій ситуації дуже важливо було знайти взаєморозуміння з клієнтом, а з самого початку це було достатньо складно. До нас приглядались, мовчали, говорили: «Ну, може бути». Треба було показувати результат, причому дуже хороший.

Один головний висновок

Треба зрозуміти клієнта.

Поділюся своїми трьома порадами у роботі з клієнтами, які я виніс з цього проекту:

1. Ставте себе на місце клієнта

Причому треба зрозуміти саме того клієнтського представника, з яким працюєш безпосередньо — власну точку контакту. Щоб побудувати з ним комунікаційний місток, треба зазирнути в його професійні бажання та страхи. А для повної картини — спілкуватися з людьми, які працюють у цій компанії. Це може звучати банально, але іноді банальностей треба просто дотримуватися — така собі дисципліна комунікацій, яка, як на мене, ні одній команді ще не зашкодила.

2. Дослідіть бізнес клієнта та слідкуйте за змінами

Треба розуміти всі процеси компанії, щоб зрозуміти, чому сталося саме так, хто винний і що робити. Іноді необхідно охопити значно ширші області. Наприклад, оцінити глобальне місце компанії на ринку, стан акцій, нещодавні угоди, загальне інформаційне поле. Можливо, це дасть підказки, які важелі саме зараз дадуть результат.

3. Інтегруйтесь у команду клієнта по максимуму

Щоб зрозуміти, що коїться з компанією-клієнтом, я спілкувався з різними менеджерами, які мали відношення до акаунту. Розпитував, знаходив кінці, вибудовував ланцюжки. Спілкувався з делівері-менеджером — він давав багато підказок, з ким як говорити, з ким можна, з ким не варто. Спілкувався із сусідньою командою сапорту і підтягнув її, щоб мотивувати її і їм було веселіше. Якщо зовсім чесно, ми з початку намагалися врахувати ризики, коли ми завершимо проект. Так і вийшло: ми пішли, а knowledge keepers залишилися, бо були залучені в цей процес.

Наостанок наголошу — communication skill дуже допомагає. Треба думати, розвиватися і дивитися ширше. Це бажано, якщо ви плануєте рости професійно. І абсолютно необхідно, якщо вже займаєте якусь координаційну роль у команді чи проекті. У такому випадку всі ниточки мають бути у вас у кулаці.

Цього разу DOU Ревізорзавітав до львівського центру розробки DataArt — сервісної компанії, яка працює з клієнтами із різноманітних індустрій: фінанси, охорона здоров’я, туризм, телеком, медіа та інтернет речей. DataArt об’єднує досвід понад 2600 фахівців із 20-тиміст Західної та Східної Європи, США, Латинської Америки. В Україні компанія представлена у Дніпрі, Києві, Львові, Одесі, Харкові та Херсоні. Львівський офіс наразі налічує 150 осіб, з них 140 — технічні спеціалісти. Усього DataArt в Україні об’єднує понад 1300 людей.

В околицях та поблизу

Офіс компанії знаходиться на 5-муповерсі будівлі за адресою вул. Смаль-Стоцького, 1. Її вигляд ззовні та всередині дуже відрізняється. Якщо дивитися з вулиці — схоже на радянський будинок, а от якщо переступити поріг офісу — потрапляєш у сучасну епоху. Як стверджують представники компанії, у Львові взагалі дуже складно знайти офіс на 100+ спеціалістів.

Поблизу офісу невеликий вибір закладів, де можна перекусити. Найближчі:

• Кафе «Львівські круасани», що знаходиться в тій самій будівлі, що й офіс. Середній чек ≈ 60-80 грн.
• Ресторан європейської та азійської кухні Crazy Town в ТЦ «Скриня», де комплексний обід буде коштувати ≈ 70 грн.
• Ресторан європейської кухні A la minute за адресою вул. Героїв УПА, 72. Середній чек ≈ 60-100 грн.
• Кав’ярня «Палярня Чехович» за адресою вул. Героїв УПА, 72. Тут також готують страви європейської кухні. Середній чек ≈ 100-150 грн.
• Бістро української кухні «Смачні Сезони» по вул. Федьковича, 38. Середній чек ≈ 50-70 грн.
• Кулінарія «Сільпо» по вул. Городоцька, 179. Середній чек ≈ 30-50 грн.

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

Робочий простір

Робочі зони тут — це великі open space простори. Усього їх 4: помаранчевий, синій, зелений і фіолетовий. Зонування за кольорами вкрай полегшує навігацію по офісу. Допомагають також різнокольорові труби в коридорах і вказівники.

Здається, у цьому офісі завжди можна знайти вільний мітинг-рум. Їх тут 34: від маленьких кабінок, розрахованих на 2 людини, до великих кімнат для переговорів, у яких вміщається до 15 осіб. Перевірити розклад і забронювати мітинг-рум можна за допомогою QR-коду, зазначеного на дверях.

Зі слів представників компанії: «У DataArt гнучкий графік роботи. Фактично те, як працюватиме колега, є предметом внутрішніх домовленостей всередині кожного проекту. Найголовніше — не пропускати важливі для проекту моменти: дедлайни, час телефонних перемовин із замовником, наради у команді тощо. Більшість спеціалістів в Україні починає роботу з 10:30-11 ізавершує її о 19:30-20:00.Але офіси відчинені цілодобово. Також можна працювати з будь-якого центру DataArt, з дому або з будь-якого іншого місця».

На одну людину в офісі припадає 10 м²площі (за даними компанії).

Відпочинок і натхнення

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

Поруч з кухнею знаходиться ігрова кімната з PlayStation. В офісі також є стіл для кікера, шахівниця і приміщення з тенісним столом і стінкою для воркаута.

На стелажі за склом представлена вся брендована сувенірна продукція, а також сувеніри із символікою міста для колег, які приїжджають до Львова у відрядження. Все це можна купити за внутрішню валюту — TYPs (Thank You Points). Їх компанія надає як додатковий бонус, а колеги вже самі надсилають їх одне одному в знак вдячності за допомогу або активну участь у корпоративних заходах.

DOU Ревізор питає

Ми поцікавились у спеціалістів компанії, як же їм живеться, і поставили два нескладних питання: що найбільше подобається в офісі та що хотілося б поліпшити або змінити.

Петро, Senior Android Developer, 6 років з компанією:

У нас є кімната для спорту — класно, можна розім’ятися. Є гардероби — можна перевзутися, переодягнутися. Взимку не доводиться сидіти і пітніти. Є душові — можна займатися спортом, приходити в офіс і освіжатися тут. Є маленькі мітинг-руми, де можна усамітнитися і сидіти в тиші. Це класно, тому що у нас опенспейс, й іноді хочеться тиші. Є lounge-рум, але я ним ще не користувався, тому що він дуже популярний. Напевно, мені найбільше подобається кухня, тому що у нас класний саппорт. От зазвичай чим заманюють? Чай, печеньки. А у нас є фрукти й усілякі ніштяки. Наприклад, для нас ріжуть і чистять кавуни. Вони навіть майже без кісточок. Хто таке взагалі робить? Думаю, це наша кілер-фіча — саппорт на кухні. Тут роблять смузі, лимонади, кукурудзу періодично варять. Є сніданки. Тобто можна взагалі не паритися. Встав зранку, вмився, приїхав на роботу і тут снідаєш.

Єдине, що мене тут непокоїть — це розташування офісу. Щоб дійти до офісу, потрібно йти повз ринок і вокзал, потім зайти на парковку. Не дуже приємно. Але це вже змінити не можна, хіба що переїжджати в новий офіс.

Ігор, Project Manager, 4 роки з компанією:

Якщо порівняти офіс, яким він був, коли ми сюди вселилися, і який він зараз, — є велика різниця. Постійно щось з’являється і покращується. Коли кожен день ходиш, може, й непомітно. А коли тиждень тебе не було — приходиш, а тут уже все помінялося. Мені тут дуже комфортно. Це одна з причин, чому я не дуже розглядаю пропозиції від інших компаній.

Сказати, що я тут щось дуже хотів би поміняти — складно. Коли щось потрібно — завжди це питання вирішується. Наприклад, коли ми вселилися, я побачив, що в мене біля стола є місце, куди можна поставити тумбочку. Я попросив тумбочку — мені її поставили. Єдине що — мабуть, крісла би ще поміняти. Тоді взагалі було б усе чудово.

Влад, Senior Java Developer / Teamlead, 9 років з компанією:

Мені подобається, що приміщення просторі. Вільно відчуваєш себе, легше дихати, ніж в маленьких кімнатках. І дружня атмосфера подобається.

Потрібні накладки на чашки. Чай гарячий. Доводиться по два стаканчики брати :) А насправді нічого більше в голову не приходить.

Оксана, Business Analyst, майже рік з компанією:

Коли ми переїхали в цей офіс, він був зовсім не такий, як зараз. З кожним днем, з кожним тижнем додавали щось нове. І коли я приїхала після vacation два місяці тому, я побачила зовсім іншу картину. Офіс-менеджери постійно щось нове придумують. Деколи навіть не встигаєш помічати, що ж вони доставили: фрукти, стенд, дошку. Дуже класно, що вони питають, що потрібно. Деякі зі стендів створили наші дизайнери — працівники компанії. Дуже подобається, що в нас на стелі є звукопоглинаючі блоки, і вони справді допомагають. Бо коли менеджери голосно розмовляють по телефону, досить важко сконцентруватися. А тепер, коли розмовляють у різних кутках, то не чути. Це приємний бонус. Також, коли ми сюди заїхали, нам запропонували дуже багато вазонів. Ти міг прийти, вибрати будь-який і поставити біля себе.

Не подобалося спочатку, що дуже багато було чути інших людей. Я ще й працюю в такій зоні, де сидять проектні менеджери. І коли у них у всіх дзвінки — це дійсно важко. Але знову ж таки тут підійшли до проблеми з креативом і постворювали маленькі спейси. Єдине, що коли приходить нова людина, то їй може бути важко зорієнтуватися. Офіс дуже великий, там синя, там зелена зона, там ще якась. Коли вже заходиш на кухню, там всі с тобою вітаються, і вже розумієш, що й до чого.

Олег, Business Analyst, 4 роки з компанією:

Локація класна, досить близько добиратися з різних кінців міста. Також близько до аеропорту, якщо якесь відрядження. Офіс просторий, кухня велика — можна поговорити з товаришами. У нас раніше офіс був на різних поверхах, то там кожний поверх живе своїм життям. А тут можна бачити всіх. Прикольно, що є переговорки, купа мітинг-румів. Немає черг ніколи. Класні фруктики ще :) Спортзальчик також допомагає, ходжу туди на турнічок — дуже розвантажує.

В принципі нормальний офіс, немає нічого радикального, що треба покращити. Ми таким займалися рік тому, коли переїхали в цей офіс. Писали списки, що тут хотілося б зробити. То ніби все вже зробили. Я особисто просив турнік — його поставили.

Ну що, ми поїхали далі ... А якщо ви хочете, щоб DOU Ревізор приїхав до вас, пишіть нам — revisor@dou.ua

Ми катаємося по Україні в пошуках найкреативніших та нестандартних офісів ІТ-компаній. Разом з нами ви зможете зазирнути за лаштунки офісного життя. Але вирішувати, гарний це офіс чи ні, будете тільки ви!

Слідкуйте за нами на Facebook — www.facebook.com/dourevisor

Підписуйтесь на відеоканал DOU Ревізор на YouTube — www.youtube.com/...​/UCYyiAq3Bn1w1V5T7y0f-Uzw

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

Основой технологии распределенного реестра (Distributed Ledger Technology, или DLT) является протокол консенсуса. Интересно, что уже на протяжении десятилетий математики и инженеры разрабатывают распределенные сети и протоколы консенсуса, но только с появлением проекта биткоина эта технология сделала значительный рывок вперед. Этот шаг сделал возможным создание приложений абсолютно нового типа. Давайте рассмотрим варианты самых популярных консенсус-алгоритмов на сегодня.

Виды консенсус-алгоритмов

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

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

Краткий обзор

Протокол — это набор правил.

Протоколы помогают:

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

Протокол — это сумма:

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

Давайте рассмотрим некоторые из этих протоколов.

Протоколы «доказательства работы»

1. Proof-of-Work (PoW — Доказательство работы)

Принцип:трудно найти решение, но легко проверить результат.

Производительность: низкая.

Среда DLT:публичный блокчейн.

Завершенность:вероятностная.

Пример использования: Bitcoin, Ethereum, Litecoin.

Блокчейн биткоина, — пожалуй, самый копируемый блокчейн. Многочисленные ноды подтверждают транзакции в соответствии с алгоритмом консенсуса PoW. Чтобы добавить новый блок, участник должен доказать, что он выполнил определенную работу. Если быть точным, он решает очень сложную задачу по нахождению хэша (hash), который соответствует определенным правилам. Первый, кому посчастливилось найти правильную комбинацию, получает возможность добавить блок в цепочку.

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

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

Протоколы «доказательства доли»

1. Proof-of-Stake (PoS — Доказательство доли)

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

Производительность:высокая.

Среда DLT: публичный/приватный блокчейн.

Завершенность:вероятностная.

Пример использования: NXT, Tezos, вскоре Ethereum.

Основная сеть Ethereum имеет характеристику полноты по Тьюрингуи работает на протоколе PoW. Однако проект планирует переключиться на более эффективный протокол, известный как Proof-of-Stake (PoS) или «доказательство доли».

Техническая особенность PoS — отсутствие сложных и ненужных вычислений. Вместо того, чтобы конкурировать с другими, участники сети дают в залог свои криптоактивы, такие как эфир (Ether) в Ethereum, и ждут, чтобы их выбрали для создания нового блока.

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

Как и в случае с алгоритмом PoW, завершение транзакции в PoS является вероятностным. Хотя транзакции относительно быстрые, по сравнению с транзакциями в сети биткоин, для этого всё ещё требуются токены. Более того, скептики указывают на тот факт, что валидаторы с крупными долями будут выбираться чаще и, стало быть, будут получать ещё больше токенов: богатые становятся богаче.

2. Delegated Proof-of-Stake (DPoS) (Делегированное доказательство доли)

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

Производительность:высокая.

Среда DLT:публичный/приватный блокчейн.

Завершенность:вероятностная.

Пример использования: EOS, BitShares.

Тем временем разработчики предложили альтернативный экономический стимул, названный Delegated Proof-of-Stake (DPoS) (Делегированное доказательство доли). Он позволяет создавать блоки на высокой скорости и обрабатывать большее количество транзакций в секунду, по сравнению с другими алгоритмами консенсуса, за счет уменьшения количества валидаторов. Во время голосования держатели монет выбирают валидаторов транзакций, которые будут формировать блоки. Вес каждого голосования определяется суммой активов голосующего. Держатели монет могут проголосовать за кандидатов в любое время. Это определяет высокую устойчивость сети: если большинство исполнителей терпят неудачу, сообщество сразу же проголосует за их замену.

Генерация новых блоков происходит каждые 1-2 секунды.Этот протокол не только быстрее, но и более справедлив, так как «делегированный» валидатор позже делится токенами со своими избирателями. Тем не менее подтверждение готовых блоков всё ещё лежит на плечах всех остальных участников сети. Daniel Larimer разработал DPoS в 2014 году. Сначала он использовал его в своём проекте BitShares, а позже в Steemit и EOS. Larimer предположил, что валидаторы DPoS будут иметь сильный стимул оставаться честными и предлагать самый быстрый и лучший сервис. В конце концов было бы глупо взломать сеть, которая хорошо вам платит. А если вы прекратите делать работу качественно, всегда есть другие участники, которые готовы занять место валидатора.

Byzantine Fault Tolerance (BFT) протоколы

До сих пор мы говорили о публичных блокчейнах, которые работают в публичной среде и нацелены на децентрализацию. Как насчёт частных предприятий на блокчейне? Что изменится, если участники будут немного больше знать о друг друге, или даже будут известны с самого старта сети (например, разные подразделения одной и той же компании)? В таких случаях можно оптимизировать консенсус-алгоритм и достичь намного большей пропускной способности. Фактически скорость увеличится в 10 раз, от сотен до тысяч транзакций в секунду, что отлично подходит для корпоративных реалий.

Важно отметить, что протоколы, «устойчивые к византийской проблеме» (BFT) — это характеристика, которой наделена или нет распределенная система. Однако в контексте нашей категоризации BFT обозначает новый класс протоколов, который не требует токенов для голосования, как в алгоритме PoW или PoS. Кроме того, он позволяет подписывать блок, даже если 1/3 участников терпят неудачу или действуют злонамеренно. BFT также решает проблему сбоев в системе и задержек в коммуникации.

1. Delegated Byzantine Fault Tolerance (DBFT) (Делегированный протокол задачи византийских генералов)

Принцип: предварительно выбранные «доверенные» участники поддерживают консенсус, даже если 1/3 из них терпят неудачу или являются злонамеренными.

Производительность: очень высокая.

Среда DLT:публичный/приватный блокчейн.

Завершенность: немедленная.

Пример использования: NEO, TON.

Этот алгоритм относится к старой задаче византийских генералов, основанной на реальном историческом событии. Используя аналогию, протоколу всё равно, если «генерал» заболел или саботировал коллег. Система будет работать, даже когда нода переходит в режим офлайн. Таким образом, консенсус протокол BFT кажется спасением от несовершенств PoW и PoS, но учитывая тысячи валидаторов, он всё равно будет бороться за решение проблемы скорости. Именно поэтому разработчики предложили делегированную модель BFT — the DBFT.

Предопределенные валидаторы в этом протоколе консенсуса позволяют значительно опередить другие протоколы. Взгляните на Ethereum с 15-20транзакциями в секунду и на NEO с почти 10 000 т/с. Действительно удобно иметь несколько известных действующих лиц, которые проверяют транзакции перед выпуском для других нод. В случае, если валидатор «сливается», участники могут делегировать новую ноду. Стоит отметить, что хоть этот протокол рассчитан на публичное окружение, он является более централизованным.

Примечание:поскольку NEO работает на протоколе PoS DBFT, члены сети не только делегируют валидаторов, но также получают нативный токен GAS, как часть доли их валидатора.

2. Practical Byzantine Fault Tolerance (PBFT) (Реализация протокола задачи византийских генералов)

Принцип: простая и быстрая реализация алгоритма BFT для приватных сетей.

Производительность:высокая.

Среда DLT:приватный блокчейн с разрешениями.

Завершенность:немедленная.

Пример использования: Hyperledger, Chain.

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

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

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

Возможно, вы также слышали о протоколе Sieve, который является усовершенствованной версией PBFT. Его особенность в том, что он умеет обрабатывать недетерминированные алгоритмы и их результаты, то есть такие, которые имеют несколькопутей обработки тех же входных данных. В BFT мире существуют также такие протоколы, как Cross Fault Tolerance (XFT — упрощенный PBFT), Paxosи Raft. Последние два особо устойчивы к сбоям системы и называются Crash Fault Tolerant (CFT).

3. Federated Byzantine Agreement (FBA) (Федеративное византийское соглашение)

Принцип:блоки валидированы, если они подписаны конкретным кворумом подписчиков.

Производительность:высокая.

Среда DLT: публичный или приватный блокчейн, не требующий разрешения.

Завершенность: немедленная.

Пример использования: Stellar, Ripple.

Federated Byzantine Agreement (FBA), или «федеративное византийское соглашение», не требует разрешения или заранее известного набора участников, в отличие от PBFT и других вариаций BFT. FBA позволяет кому-либо присоединиться к сети. Транзакции в этом протоколе валидируются фиксированным количеством участников, которые выбираются из тех, кто в тот момент находятся в сети.

Примечательно, что по правилам FBA существуют Gateways (шлюзы) и Market-Makers (мэйкеры), которые обеспечивают честность и ликвидность сети. Первые выступают в роли традиционных банков, владеющих финансовыми средствами и создающих их эквивалент в виртуальных токенах. Вторые — ведут учетные записи с многочисленными шлюзами и сразу в нескольких валютах.

Краткое резюме

• Proof-of-Work стал первым и самым надежным протоколом консенсуса для публичных блокчейнов, таких как Bitcoin и Ethereum, однако он энергозатратный.
• Proof-of-Stake не требует сложных вычислений. Вместо этого, он поощряет пользователей закладывать собственные средства для выполнения эквивалентного количества проверок транзакций и предполагает, что все будут действовать рационально.
• BFT является упрощение концепции PoS, которая делает её намного быстрее. Однако BFT протоколы практичны только в небольшой и приватной среде.
• PBFT — это проверенное решение для приватных распределённых систем. Быстрый и надёжный протокол, но очень зависит от пропускной способности.
• DBFT улучшает BFT, позволяя участникам сети делегировать ответственность на валидаторов. Этот протокол, в отличие от PBFT, может быть использован в публичной среде. Очень быстрый, но более централизованный.
• Хотя вышеупомянутые варианты BFT являются блокчейнами, требующими разрешения, чтобы быть допущенным к сети, FBA является открытым для участия и часто не требует разрешения.
• Есть и другие протоколы...

«Неблокчейны»

Исследователь Сергей Попов провел мысленный эксперимент: а что, если мы сможем полностью избежать блоков?

1. Directed Acyclic Graph (DAG) (Направленный ациклический граф)

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

Производительность:высокая.

Среда DLT:публичный неблокчейн с разрешениями.

Завершенность:вероятностная.

Пример использования: IOTA, ByteBall.

Основная проблема с блокчейном — это его синхронная природа. Блокчейны не могут быть параллельными. Можно изменить размер или частоту блоков, а также участников, которые их валидируют, но в итоге вся история событий будет заточена в строгую линейную последовательность. В качестве альтернативы, технология Directed Acyclic Graph (DAG) является асинхронной, что даёт конкурентное преимущество одновременных событий.

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

2. HashGraph (ХэшГраф)

Принцип:ноды связываются случайным образом с использованием протокола «gossip about gossip» и соглашаются на консенсус после определенного раунда коммуникации.

Производительность:очень высокая.

Среда DLT:приватный неблокчейн с разрешениями.

Завершенность:зависит от раунда.

Пример использования: HashGraph.

Разработчики этого протокола утверждают, что блокчейн является устаревшей системой. В качестве замены они также выступают за концепцию DAG. Однако ключевым отличием HashGraph является протокол «gossip about gossip», где нода получает набор транзакций с меткой времени, о которых «знает» другая нода. Для работы такого алгоритма все участники в сети должны быть известными. В результате синхронизации каждая нода хранит всю информацию и историю получения этой информации всеми нодами сети. Как только нода видит в своей истории, что конкретное сообщение уже было получено и проверено большинством, нет сомнений, что оно действительно.

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

Примечание:недавно проект обновился и переименовался в Hedera Hashgraph. Некоторые наработки теперь доступны на GitHub.

Другие протоколы консенсуса для конкретных задач

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

1. Proof-of-Activity (PoA) (Доказательство активности)

Принцип:гибрид PoW и PoS.

Производительность:низкая.

Среда DLT:публичный, не требующий разрешения блокчейн.

Завершенность:вероятностная.

Пример использования: Decred.

Proof-of-Activity (PoA) объединяет протоколы PoW и PoS, что означает, что участники могут как майнить, так и закладывать долю для валидации блоков. Итак, протокол PoA обеспечивает баланс между майнерами и обычными участниками сети.

2. Proof-of-Location (PoL) (Доказательство местоположения)

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

Производительность:средняя.

Среда DLT:общественный, не требующий разрешения блокчейн.

Завершенность:немедленная.

Пример использования: FOAM, Platin.

Proof-of-Location (PoL) позволяет пользователям закрепить за собой конкретную GPS-локацию и таким образом аутентифицировать себя в сети. Интересно то, что протокол опирается на BFT маячки (beacons), которые записывают геолокацию и маркеры времени в блокчейне, что предотвращает сбои и мошенничество в системе.

3. Proof-of-Importance (PoI) (Доказательство важности)

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

Производительность:высокая.

Среда DLT: общественный, не требующий разрешения блокчейн.

Завершенность:вероятностная.

Пример использования: NEM.

Алгоритм консенсус Proof-of-Importance (PoI) (доказательство важности)действует почти как PoS, но включает в себя три компонента:

• количество токенов на счету;
• активность операций счета;
• время, проведенное владельцем счёта в сети.

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

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

4. Proof-of-Elapsed-Time (PoET) (Доказательство прошедшего времени)

Принцип:блоки создаются в доверенной среде с равными периодами.

Производительность:средняя.

Среда DLT:частный блокчейн, с разрешениями и без них.

Завершенность: вероятностная.

Пример использования: Intel.

Производитель чипов Intel не отставал и разработал собственный блокчейн под названием IntelLedger. Алгоритм консенсуса IntelLedger называется Proof-of-Elapsed-Time (PoET) или «доказательство прошедшего времени». Сегодня он присутствует в одном из Hyperledger-продуктов.

Эта система похожа на Proof-of-Work, но потребляет гораздо меньше электроэнергии. Вместо того, чтобы участники решали криптографическую головоломку, алгоритм работает в среде надежного выполнения (Trusted Execution Environment, TEE), такой, как Intel Software Guard Extensions (SGX). Протокол PoET также гарантирует, что блоки создаются случайно, но без какой-либо необходимой работы.

В качестве решения Intel предлагает гарантированное время ожидания согласно TEE. По информации компании, алгоритм PoET можно масштабировать до тысяч нод, и он будет корректно работать на любом процессоре Intel, поддерживающем SGX. Однако разве блокчейн не должен помогать нам избегать третьих сторон, а не полагаться на них?

Заключение

Протоколы консенсуса являются неотъемлемой частью распределенных систем. В первую очередь они помогают достигать справедливости, избегать сбоев системы, когда один из участников — нод — выходит из строя. Во-вторых, децентрализованная среда требует решения, которое поможет двигаться вперёд и изменять общее состояние, даже в среде, где никто никому не доверяет. Определенные правила помогают достичь «консенсуса».

Мы рассмотрели самые популярные протоколы, которые применяются уже в десятках проектов. Есть ещё много других и более экзотических протоколов, таких как Cross Fault Tolerance (XFT), Paxos, Sieve, Raft, Proof-of-Stake-Time (PoST) и Proof-of-Brain (PoB), которые мы просто не смогли вместить в эту статью, но обязательно опишем в следующих публикациях. Если же у вас есть вопросы, оставляйте комментарии под статьей.

Ionic — это технология, позволяющая разрабатывать полноценные приложения для iOS и Android. Для этого не нужно иметь глубокие знания в каждой из платформ. Конечно же, есть некоторые ограничения, но в целом необходимо быть знакомым с Angular (популярный веб-фреймворк), чтобы начать разработку приложения. Для применения стилей можно использовать SCSS — это придаст приложению нужный вид. В этой статье рассмотрим главные преимущества и недостатки Ionic.

В Ionic есть встроенная библиотека стандартных элементов, которые можно использовать аналогично элементам Bootstrap: карточки, кнопки, переключатели, сегменты, попапы, поля ввода, списки, сетка из строк и колонок и т. д. По умолчанию эти элементы меняются так, чтобы выглядеть как нативные на iOS и Android, но их вид можно изменить и при необходимости.

Также с Ionic вам доступно множество плагинов, которые позволяют использовать железо смартфона (Ionic Native/Cordova). Но не забудьте проследить, чтобы ваши платформы активно поддерживали выбранные плагины. В большинстве случаев такие плагины работают хорошо, но иногда может возникнуть ошибка билда или конфликт даже с широко используемыми плагинами вроде входа через Facebook или Firebase Analytics. Такие проблемы обычно решаются либо чисткой и ребилдом проекта, либо обновлением плагина (при условии, что уже есть его новая версия, которая решает проблему). Также можно заменить плагин на альтернативный или в некоторых случаях — добавить параметры, разрешающие перезапись в config/xml/.

Несколько заметок о нашем опыте с определёнными Ionic Native/Cordova модулями:

• Для правильной работы некоторых плагинов потребуется тонкая настройка, например глубинных ссылок — модуль легко подключить, но сложно заставить работать как следует.
• Для работы входа через Facebook в консоли Facebook для разработчиков понадобится добавить base64, использованный для подписи вашего приложения.
• «Поделиться на Facebook» открывает сообщение, но его нельзя заранее заполнить нужным текстом. Однако можно показать пользователю подсказку о том, что текст или ссылку можно вставить. При этом важно использовать только валидные HTML-ссылки.
• Также мы использовали следующие плагины без больших сложностей: Поделиться на Twitter, Копировать в буфер обмена, Выбрать изображение из галереи/использовать камеру, Обрезать изображение, Блокировка поворота экрана, Браузер в приложении, вызов редактора email, а также Локализацию/Глобализацию.

У Ionic есть ещё один большой плюс — скорость разработки. Поскольку он основан на Angular, проект на Ionic можно запускать в браузере и видеть, как будет выглядеть приложение во время разработки. Для того чтобы увидеть такое превью, не обязательно устанавливать приложение на смартфон или эмулятор. Это существенно помогает экономить время при изменении UI. А когда вы работаете над функциями, требующими проверки на смартфоне (например, сделать фото), сборка билда и установка его на смартфон займет всего несколько минут. На Android устанавливать приложения можно прямо из командной строки, а на iOS билд нужно открыть в Xcode.

Гибридные vs нативные приложения

Недавно появилось несколько фреймворков, позволяющих разрабатывать настоящие нативные приложения с использованием Angular (NativeScript) или React (React Native). Они имеют важное преимущество перед гибридным подходом Ionic — ничто не может сравниться с производительностью нативных приложений. Однако нативные приложения имеют не менее важный минус. Используя Ionic, вы работаете с HTML- и SCSS-файлами, а для нативной разработки вам понадобятся другие навыки для работы с разметкой и стилями. Этих навыков нет у большинства веб-разработчиков.

Деплой в Google Play Store

Чтобы выпустить завершенное приложение, вам понадобится его сначала собрать:
ionic cordova build android --prod --release. Затем его нужно подписать с помощью jarsigner (инструмент для подписи APK), используя свой JKS-ключ и zipalign (инструмент для превращения подписанного приложения в APK в готовое для загрузки на Google Play Store). При этом важно использовать тот же JKS-ключ, который загружен в вашу консоль разработчика Play Store.

iOS

Исходя из нашего опыта, Ionic для iOS не настолько отлажен, как для Android. Мы сталкивались со странным поведением такого элемента разметки, как сегмент — иногда он может конфликтовать со скроллингом. Также многие элементы требуют отдельных SCSS- стилей для того, чтобы они выглядели как вам нужно на обеих платформах. То же относится к плагину Flurry Analytics. Его легко установить и использовать в Android, а на iOS этот плагин не устанавливался простыми способами и потребовал использовать CocoaPods — пакетный менеджер для установки плагинов на iOS. И даже после правильной установки этот плагин не инициализируется так же, как на Android.

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

Плюсы

• Быстрая разработка и минимальное время выхода на рынок.
• Можно вести основную часть разработки в браузере (кроме нативной функциональности смартфона — тут понадобится использовать смартфон для дебага).
• Можно разрабатывать приложение для iOS и Android одновременно (с некоторыми ограничениями — такими как особенности платформ, касающиеся стилей и плагинов).
• Навыки в Angular, HTML, CSS и JavaScript — это практически всё, что понадобится для начала разработки. Нет необходимости знать Java и Swift или Objective-C.
• Множество UI-компонентовдоступны и просты в использовании — карточки, кнопки, переключатели, сегменты, попапы, поля ввода, списки, сетка из строк и колонок и т. д.
• Множество плагинов, позволяющих использовать функции смартфонов, такие как: камера, сканер отпечатков пальцев, NFC, геолокация, отправка аналитики на Firebase, оповещения и глубинные ссылки.

Минусы

Нативные плагины могут стать проблемой, если какие-то из используемых плагинов конфликтуют или если в одном из них баг. Например, недавно в плагине для логина с помощью Facebook был баг: если юзер хоть раз сделал log out, то больше логин уже не работал. А плагин FCM (Firebase Cloud Messaging) не работает с firebase-analytics. Но есть плагин под названием Firebase, которым можно заменить их оба. Дебаг может быть довольно сложным: иногда трудно понять, откуда приходит ошибка, поскольку сообщения об ошибках могут быть неинформативными.

Билд может ломаться без причин, что-то оказывается поврежденным в оригинальной папке. Так что делайте коммиты часто и используйте ветки для каждой новой функции или страницы. Если что-то сломается, просто сделайте клон репозитория в новой папке, запустите npm install и попробуйте собрать проект заново.

Вывод

Ionic — отличная технология, позволяющая сделать готовое для выпуска приложение гораздо быстрее, чем при традиционной разработке. Большой плюс этого подхода — то, что вместо Java/Swift/Objective-C можно использовать стандартные технологии веб-разработки, такие как HTML, CSS, JavaScript/TypeScript и Angular. Есть небольшой минус в производительности — нативное приложение может быть более отзывчивым на старых устройствах, но на любом современном смартфоне разница будет незначительной.

Всем привет, я Александр Гончар — AI Solution Architect в Mawi Solutions. Занимаюсь разработкой и внедрением state of the art решений для анализа биосигналов. В этой статье я расскажу про то, что делают исследователи в области искусственного интеллекта и как идеи из research переносятся на прикладные задачи, в чем их ценность и как начать заниматься более продвинутым машинным обучением.

Дисклеймер: речь пойдет не о новых «ResDenseXYZNet», которые на ImageNet дали еще плюс 0.05% в точности и надо срочно стянуть их модельки с GitHub, а более интересных и фундаментальных вещах :)

Как я пришел в Machine Learning

Для меня путешествие в мир машинного обучения (далее я буду жонглировать фразами «искусственный интеллект», «машинное обучение», «data science» как взаимозаменяемыми) началось давно. Это было летом после вымученного первого курса КПИ на кафедре прикладной математики, куда я поступил после окончания гимназии с углубленным изучением иностранных языков.

После первых двух сессий, когда я оказывался в шаге от отчисления, я начал задумываться над тем, что раз меня уже забросило в математику, то надо найти мотивацию и желание заниматься ею профессионально. Я просто начал гуглить что-то вроде «what applied mathematicians do» и относительно быстро узнал про тогда еще не настолько популярную область как machine learning. Мне понравилось, и я начал учиться по случайным урокам в интернете и, конечно, на знаменитом курсе Andrew Ng.

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

О создании портативного кардиографа

Сегодня я заканчиваю магистратуру по математике в University of Verona, веду относительно популярный блог на Medium, читаю публичные лекции и отвечаю за машинное обучение в компании Mawi Solutions, где мы разработали свой портативный кардиограф на «стероидах» в виде машинного обучения. Почему кардиограф и сердце? Как минимум потому, что именно болезни сердца являются убийцами номер один в мире, и доступность анализа состояния сердца, хотя бы на уровне определения мерцательной аритмии и других сбоев ритма сердца, позволит спасти множество жизней за счет того, что человек сможет делать электрокардиограмму (ЭКГ) каждый день дома, а не у врача раз в пару лет, когда уже может быть поздно.

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

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

Конкуренция за искусственный интеллект

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

Конкуренция идет на нескольких уровнях. На уровне цифр — процента правильных решений, затраченного времени на разработку, скорости принятия решений в реальном времени, количества сэкономленных денег и других бизнес-показателей, ради которых это все в итоге и делается. И на уровне сложности инновации. У кого-то чат-бот, который на самом деле представляет собой кучу легаси кода с rule-based принятиями решений, с десятками версий, которые отдельно заточены под каждый из языков клиентов. А у кого-то state of the art нейронка, которая сама справляется с разными языками, да еще и есть speech synthesis алгоритм, так что можно не только попереписываться, а и поболтать.

В каком-то стартапе, связанном с диетологией, нейронка распознает 100 типов еды на картинке и записывает их названия, а у кого-то — 10000 блюд, да еще и автоматом подсчитает калориии сгенерирует рецепт. В задачах первого уровня часто можно соревноваться с помощью инженерии (оптимизировать код, инфраструктуру, нанять специалиста из более толкового универа, который даст +3.76% к точности) и UI/UX или продакт-дизайнера (более удобная интерпретация outputs нейронки, выбор правильных метрик). Со вторым все несколько сложнее — это уже вопрос настоящих исследований или адаптации существующих state of the art решений для конкретного продукта.

Как обучается ИИ

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

• Дайте мне много (или не очень много) примеров входных и выходных данных.
• Через какое-то время (от пары минут до недели) я научусь более-менее точно по более-менее похожим входным данным давать правильные выходные данные.

Например, в моем случае это могут быть 10 тысяч 30-секундныхучастков ЭКГ разных людей. Я хочу, чтобы алгоритм научился говорить для каждого участка, есть ли там аритмия или нет. То же самое происходит для изображений, видео, звука, временных рядов, заданных профилей клиентов и так далее. Как бы учился среднестатический человек?

• Не просто смотрит на изображения, которые надо отнести к какой-то категории, а взаимодействует с контекстом, в котором эти изображения были получены. Более того, изображения человек будет «фотографировать» и анализировать сам, какие помогают решать задачу, а какие — нет (методом проб и ошибок, в отличие от supervised learning, где мы просто даем кучу картинок с тегами) (вот вам и reinforcement learning).
• Не нужно много примеров объектов, чтобы разобраться в них. Зачем мне смотреть на тысячу изображений собак раз эдак по двадцать, чтобы понять, что это собака? (one-shot learning, few-shot learning, bayesian machine learning).
• Соответственно не нужно много времени на обучение (теория оптимизации).
• Может приспосабливаться к разным условиям. Ребенок, увидев котиков в книжке, с легкостью узнает их и в жизни, и на экране, даже в карикатурном виде (domain adaptation, transfer learning).
• Может переносить знания и опыт с одной предметной области на другую (transfer learning, meta-learning).
• С каждого канала информации, например слухового, одновременно берет много информации: кто говорит, какая интонация, какие конкретно слова и их смысл, какие фоновые звуки и так далее (multitask learning).
• И наоборот, если мы хотим узнать что-то одно, например, определить эмоцию, с которой человек что-то говорит, то полезно и увидеть его, и услышать, и понять текст, который он произносит, а иногда даже дотронуться до руки (multimodal learning).
• Может объяснить и мотивировать свои решения (interpretable AI).
• И многое-многое другое (память, абстракции, ethics, logical reasoning, эволюция мышления и так далее).
• ... и чтобы все это вообще автоматически делалось! (autoML).

Хорошая новость в том, что для прикладных задач нам не всегда нужно абсолютно все вышеперечисленное, но как минимум парочка пунктов бывают очень полезны. Нужна ли вам нейронка, которая работает с голосом только восточно-европейского акцента английского (это я про domain adaptation)? А если у вас автоматизированная инвестиционная система, вы точно будете доверять ей, как магической коробочке, при сделках на миллионы долларов или все-таки попросите объяснения (interpretable AI)?

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

Multitask learning

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

Рассмотрим простой пример: распознавание эмоций на лице человека. На вход — фотка лица, на выход — одна из 7 базовых эмоций (радость, грусть, злость, удивление, отвращение, страх, презрение). Сейчас нейронка должна сама как-то выучить соответствие пикселей, отвечающих за разные части лица разным эмоциям. А что если мы ей поможем, задавая напутствующие вопросы: «А поднялись ли брови?», «Открыт ли рот?». Фишка в том, что эти вопросы мы подаем именно как дополнительные задачи, которые это нейронная сеть должна научиться решать. Более того, мы можем покреативить дальше и добавить новые «подсказки», например, на основе того, что разные этнические культуры выражают свои эмоции по-разному. И это работает!

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

Как начать заниматься исследованиями и воплощать идеи в жизнь

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

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

После того как мы разобрались с математикой, самое время начать ее воплощать в жизнь. С этим проще — надо всего лишь овладеть парой-тройкой основных инструментов для scientific computing, которые по совместимости и будут инструментами для машинного обучения. Экосистемы Tensorflow, NumPy и scikit-learn будут практически безошибочным выбором. Основной критерий тут — навык запрограммировать прототип алгоритма машинного обучения из любой статьи. Как находить такие статьи? Я уже писал об этом в своем блоге, поэтому не буду повторяться. Вкратце: следите за конкретными организациями и личностями из мира ИИ и о чем они между собой общаются.

И последнее: как же делаются рисерчи? Он самый простой, по крайней мере в контексте прикладных исследований. Вы просто берете проблему, которую вы или кто-то другой уже решает «обычным» способом, идею из статьи, которая, возможно, вообще не касается вашей задачи. Немного думаете над тем, могут ли они полюбить друг друга, и если да — соединяете их. Например, вы увидели статьюпо domain adaptation в компьютерном зрении и сразу подумали о том, как это поможет в вашем бизнесе по анализу видео, где датасеты есть в Full HD, а у вас старые видеокамеры висят. Или впечатлились, например, моделями, которые могут переводить с одного языка на другой, не имея параллельных текстов. Грубо говоря, модель учится переводить с английского на немецкий, имея две абсолютно разные книги. И вы вспомнили про свою ситуацию в анализе сигналов, где вам хорошо бы приводить данные с акселерометров разной природы к одному типу, а параллельно записывать с них возможности нет. Круто же!

Выводы

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

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

И еще 24 ноября на конференции Data Science UA я буду рассказывать более детально о том, что такое multitask learning, почему он работает, какие есть кейсы и state of the art решения в этой области исследований. А еще в тот же день проведу мастер-класс — будем запускать код, учить нейронки и все такое. Приходите, я буду очень рад всех видеть и пообщаться.

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

Обзор будет полезен системным администраторам, специалистам DevOps, клиентам, которые сотрудничают с IT-сервисами и разработчикам.

TICK Stack — бесплатный комплекс программ, простой в использовании и гибкий в настройке, с механизмом агрегации и удобными кастомизируемыми функциями выбора.

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

Структура TICK Stack

Это ядро ​​с открытым исходным кодом или стек TICK, состоящий из четырех модулей: Telegraf, InfluxDB, Chronograf и Kapacitor.

Рассмотрим каждый компонент отдельно.

Telegraf

Telegraf — управляемый плагином сервер для сбора показателей и отчетности. Telegraf интегрируется с разнообразными метриками, событиями и логами, обращаясь непосредственно к контейнерам и системам, в которых он работает, достает метрики из сторонних API или даже прослушивает показатели через сервисы ConsumerD и Kafka. Он также имеет выходные плагины для отправки показателей во множество других хранилищ данных, служб и query-сообщений, включая InfluxDB, Graphite, OpenTSDB, Datadog, Librato, Kafka, MQTT, NSQ.

InfluxDB

InfluxDB — Time Series Database, построенная с нуля, для обработки высоких нагрузок на запись и запрос. InfluxDB — это специализированное высокопроизводительное хранилище данных, написанное специально для временных данных (мониторинг DevOps, метрики приложений, данные датчика IoT и аналитика в реальном времени). Оно позволяет сохранять пространство на своем компьютере, настраивая InfluxDB для хранения данных в течение определенного периода времени и по его истечению — автоматического удаления любых нежелательных данных из системы. InfluxDB использует язык запросов, подобный SQL, для взаимодействия с данными.

Chronograf

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

Kapacitor

Kapacitor — собственный механизм обработки данных. Он может обрабатывать как потоковые, так и пакетные данные от InfluxDB. Kapacitor позволяет подключать собственную пользовательскую логику или пользовательские функции для обработки предупреждений с динамическими порогами, сопоставления показателей для шаблонов, вычисления статистических аномалий и выполнения определенных действий на основе этих предупреждений, таких как динамическая перебалансировка нагрузки. Kapacitor интегрируется с HipChat, OpsGenie, Alerta, Sensu, PagerDuty, Slack и т. д.

Как это работает

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

С помощью инструмента мы можем проверить: CPU, RAM, место на жестком диске, интенсивность сетевого трафика, количество соединений с веб-сервером, запросы на сайты, MS SQL запросы, количество операций записи и чтения, RabbitMQ.

Если вам нужна дополнительная функциональность, можно обновить инструмент плагинами из list of opportunities.

Системные характеристики сервера

Этот борд показывает использование CPU, использование диска, Lead, Memory Gigabytes Used, Network Mb и т. д.

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

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

Выше приведены диаграммы двух серверов Windows: процессор и оперативная память. Это три графика с тремя параметрами для двух серверов (шесть параметров), которые одновременно демонстрируются на экране.

Зависимости и прогнозирование

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

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

Простая и настраиваемая система оповещений

TICK позволяет настроить уведомления через удобные каналы, которые будут отвечать задачам конкретной системы мониторинга и поддержки. Оповещения могут быть направлены в Slack, Page Duty, Telegram и так далее.

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

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

Так выглядит классификация алертов для оповещений с настраиваемой системой приоритетов (низкий и высокий приоритет алерта).

Как работает приоритетность алертов

Предупреждение появляется в специальном канале в Slack. Это очень удобно. Не нужно открывать дополнительное приложение или браузер. Slack широко используется.

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

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

Кто может использовать TICK

TICK ​​- полезный технический стек для таких специалистов:

Разработчики

Большое количество плагинов, таких как: MySQL,MS SQL. Elastic Search, RabbitMQ и другие, — могут помочь разработчикам отслеживать узкие области использования программного обеспечения и повышать эффективность работы.

Администраторы

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

Клиенты

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

Заключение

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

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