Rebrain

Данила Мигалин (@miga) живет в Вильнюсе и работает инженером в Uber.

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

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

Мы поговорили с Данилой, и он рассказал, почему в Uber нет разделения на девов и опсов, трудно ли осваивать разработку, если всю жизнь был админом и почему Golang стал стандартом в сфере Devops.

Трудно ли админу стать разрабом, а разрабу админом

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

Сейчас мы все называемся Software Engineer и пишем код каждый день. В Майкрософте мы назывались Service Engineer (уже не Operations, но еще не Software Engineer) и занимались девопской работой. Писали разработчикам разные автоматизации для деплоя.

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

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

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

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

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

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

Круто, что в Uber дежурства, что называется, follow the sun. Когда у нас ночь дежурят пацаны по другую сторону океана. Нам остается день. До этого мы дежурили круглосуточно. У нас были проекты, которые мы делали в Вильнюсе, и были проекты из Сан-Франциско. Мы за свои проекты онколили 24/7 и ребята из Сан-Франциско онколили за свои проекты 24/7. Потом провели ряд вебинаров, рассказали что к чему друг другу и начали онколить днем за свое и за американское, а они своим днем за свое и за Вильнюсское.

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

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

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

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

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

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

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

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

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

Так было всегда.

Тренд на перемены есть, разработчиков начинают потихоньку приучать.

Сейчас вакансию бэкендера без докера уже не найти. Ладно, а в обратную сторону это работает? Ты же не занимался продуктовой разработкой в конвейерном смысле. Сложно было?

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

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

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

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

Мне кажется, нет особой проблемы в том, чтобы изучить +1 язык программирования. Я бы не испугался Java.

Почему Golang стал стандартом в сфере Devops

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

При переходе с Питона на Golang я не испытал страха. Golang в тысячу, в миллиард раз проще, чем Питон. Ты буквально можешь открыть http://tur.golang.org/, пройти его за день и на утро писать в продакшн. Я не шучу, это действительно так.

Но есть одно но. Golang очень простой и поэтому не выразительный. Лично меня это раздражает.

Знаю ребят, которые с Java переходят на Scala, потом на Хаскель, потом на Идрис, и все равно им не хватает выразительности.

Да, я постоянно страдаю. Пишу код и думаю, блин, занимаюсь ерундой! Будь это Erlang, я бы воспользовался паттерн-матчингом, все было бы изящненько, красивенько. С Golang никакого эстетического удовольствия. Он не про изящность. Это в Питоне ты можешь написать какой-нибудь comprehension и, откинувшись на спинку кресла, любоваться им 5 минут: как ловко получилось. Мало возможностей проявить хоть какую-то творческую жилку. Уверен, что топорность Go была одной из целей создания языка, чтобы гугловские ребята, вся эта армия программистов, не занималась творчеством, а просто писала понятный и надежный код.

Вы и разработку, и автоматизацию девопс тоже на Golang делаете?

Да, конкретно в нашей архитектуре нет такого разделения. Это все сервис. Просто один обслуживает юзерский трафик, другой оркеструет контейнеры.

Моя команда занимается автоматизацией баз данных. Мы предоставляем базы данных как сервис внутри Uber. У нас для этого есть свой оркестратор. Как кубернетес, только убернетес! Мы пишем этот оркестратор каждый день. Пишем его на Golang.

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

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

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

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

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

Думаю, человек не из индустрии понятия не имеет, кто такой девопс. Я скажу программист. Я так и говорю. Это же всем понятно.

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

Интервью с Антоном Черноусовым из Yandex.Cloud

Антон Черноусов developer advocate пришел в Yandex.Cloud, чтобы заниматься микросервисами, популярными в индустрии Docker и Kubernetes . Но главная его профессиональная страсть это Serverless. Мы поговорили с Антоном, и он объяснил, почему бессерверные платформы ждет большое будущее.

Зачем изучать Serverless

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

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

Docker и Kubernetes это инструменты. Как и любой инструмент, они не вечны. У каждого инструмента есть жизненный цикл. Как только мы переходим в высокотехнологичную сферу, жизненный цикл инструмента сильно укорачивается. Под этим углом я смотрю на технологии. Именно поэтому приходится следить за тем, что будет следующим новым молотком на ближайшие 2-3 года. Три года назад нужно было обратить внимание на Docker. Два года назад на Kubernetes. Сейчас нужно изучать Serverless.

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

Должны ли обычные разработчики думать о Serverless

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

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

Но это все наши внутренние заморочки. Бизнес интересует стоимость конкретного процесса и скорость его реализации.

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

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

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

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

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

Как Serverless устроен на практике

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

Сейчас, когда я говорю про серверлесс, я подразумеваю все подмножество технологий:

Функция

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

База для хранения состояния

Вторая часть необходима для того чтобы сделать полноценное приложение. Когда мы выдерживаем нагрузку, нам нужно место, где мы будем хранить состояние. Там есть развилка: оперативное состояние и долговременное. Для долговременного состояния подходят БД. Уже появился целый класс баз данных, который так и называется Serverless Database.

В Yandex.Cloud это проект Yandex Database, у которого в прошлом году появился серверлесс вариант запуска. Приходит нагрузка, она автоматически масштабируется, ты платишь только за те операции, которые совершил.

Оперативное управление данными

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

У Амазона это SQS, в Yandex.Cloud Message Queue. Она работает именно в этой идеологии масштабируемое Serverless решение.

Хранилище

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

В Амазоне это S3, как прародитель, в Yandex.Cloud это Object Storage, который повторяет, по сути, протокол S3. Это возможность хранить и файлики, и статическую информацию, и долговременно хранить бекапы.

API

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

Есть сервис API Gateway. Он позволяет заявить наружу тот самый API, которым мы управляем, предоставить доступ к функциям и связать API вызов с конкретной функцией.

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

Почему весь рынок все еще не перешел на Serverless

Вижу три момента, которые влияют на переход и толкают к нему.

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

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

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

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

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

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

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

Сейчас в русскоязычном пространстве мало кейсов и практик использования Serverless и я стараюсь это исправить в рамках Yandex Serverless Ecosystemи хаба Serverless тут на Хабре. Например, недавно я был у мамы и нашел книжку-игру. Были такая серия Подземелья черного замка. Это фэнтези-роман, который разыгрывается с помощью кубиков. Можно было взять в дорогу и играть в поезде. Каждый абзац книги был пронумерован и содержал действие. Ты управлял персонажем, который ходил по книге и выполнял задания спасал принцессу, боролся с темным властелином.

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

В результате, популярность Serverless это вопрос времени и нашей тяги к саморазвитию.

А что вы думаете про Serverless? Заходите к нам в сообщество там мы постоянно разбираем различные проблемы и задачи из сферы Devops, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.

Алексей Миловидов работал инженером в Яндекс.Метрике, и перед ним стояла непростая задача.

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

Долгое время такая СУБД разрабатывалась только для внутренних нужд но в 2016 вышла в опенсорс под названием ClickHouse, и сообщество встречает инструмент по-разному.

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

Расскажи про себя, про учебу, и про первый опыт в разработке.

Наверное, надо начинать очень издалека. В семье было еще два брата, я самый младший. Году в 90-м родители купили старшему брату бытовой компьютер БК-0010. Это была реально классная машина. Интересные игры, встроенные языки программирования: Бейсик Вильнюс 86 и Фокал (Focal, акроним от англ. formula calculator).

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

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

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

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

Это история была общей для всех программистов. Все учили С++, чтобы делать игры, а в итоге делают КликХаус.

Почему КликХаус настолько быстрее аналогов?

Тому есть две причины. Одна причина это просто более-менее подходящие технические решения. А вторая внимание к деталям. КликХаус был создан для обработки данных веб-аналитики в Яндекс.Метрике. Я решал задачи производительности. Что-нибудь подкрутить, как-нибудь схитрить, чтобы КликХаус работал хотя бы в 2 раза быстрее. Как только ты сделал его в 2 раза быстрее, сразу думаешь: а как еще в полтора раза быстрее сделать? А еще бы на 30%, и вообще было бы идеально! Приходится много ковыряться в деталях.

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

В такой работе должен быть инженерный кайф.

Да, он определенно присутствует. Представь, что ты наконец-то сделал решение, (может быть, впервые в жизни!), про которое ты можешь сказать: да, это лучшее решение в мире.

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

Но компаниям на самом деле наплевать, как ты перекладываешь джейсоны. Жрет оно в 5 раз больше оперативы, и бог с ним!

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

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

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

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

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

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

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

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

И как такие проблемы решаются? Ты их один решаешь, или у вас там консилиум собирается? Бывают ли тупики?

А теперь раскрою секрет, вот такие проблемы мы не решаем! Мы еще до этого не дошли. Мы просто научились наблюдать.

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

Есть и другие способы измерять производительность. Что называется, always on profiling. То есть всегда включенное профилирование на продакшене. В КликХаусе встроен семплирующий профайлер. С небольшим интервалом семплирования, всего лишь один раз в секунду, собираются стектрейсы во всех потоках. А потом по большому кластеру мы агрегируем все за неделю и делаем выводы, стал ли продукт быстрее.

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

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

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

В C# или Java хороший код это максимум 200 строк на файл. Ты заходишь в любой файлик, и он умещается в экран. На C++ это вообще нереально, особенно на больших проектах. У вас есть файлы на 5.000 строк?

Сейчас посмотрю мой любимый StorageReplicatedMergeTree.cpp, сколько там строк...

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

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

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

...итак в нашем файле 6.368 строк. Это один из самых больших файлов в нашем проекте. Таких немного. В основном у нас небольшие файлы.

Зачем КликХаус в опенсорсе?

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

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

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

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

В конце 2015-го года я перешел в группу Кликхаус (ее выделили из группы Яндекс.Метрики). Мы обсуждали идею КликХауса на опенсорсе с моим руководителем, он предложил ее Михаилу Парахину (тогда он был СТО в Яндексе). Тот дал добро. Я тогда написал мотивационное письмо: какие возможности, какие риски. Мы стали пробовать, несколько месяцев ушло на подготовку, но летом 2016 года все было готово, и мы выложили КликХаус в опенсорс. Серьезных надежд не было. У меня был такой принцип: если ничего не получится, то ну и ладно, не надо будет тратить силы. Но если полетит и все будет хорошо, то у нас будет некоторое достижение. Возможность получить это достижение перекрывала риски.

Взлетела технология?

Уверенно растет. Будем стараться дальше.

Опенсорс принес какие-то плоды? Контрибьюторы со стороны приходят?

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

Слушай, вас очень ругают за документацию.

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

Почему Кликхаус так сильно отличается от других БД, что даже появилось выражение "ClickHouse way"?

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

Не страшно принимать такие решения? Привычка сообщества это тоже часть простоты инструмента.

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

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

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

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

Я всецело это приветствую. Чем больше будет этот бизнес, тем лучше.

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

Ничего, придется объяснять. Такое часто бывает. Взять линукс или BSD, в котором многие вещи тянутся из допотопных времен. Например, спрашивают, почему язык csh такой ужасный? Чем разработчик думал, когда его писал? Автора нашли (хотел сказать откопали). Он ответил: у меня просто не было опыта. Какую технологию не возьми, везде есть какие-нибудь грабли.

Как тебе индустрия прямо сейчас?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Невероятно важно осознавать все то, что привело к этому.

От редакции Rebrain

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

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

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

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

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

Покупка компании обошлась недорого, но содержание такой инфраструктуры стоило заоблачных денег. Индусы использовали дорогущую Vertica, где, кроме оплаты железа, нужно было еще отстегивать за лицензию. Мы решили попробовать переезд на ClickHouse. Это практически бесплатный аналог Vertica. Оба продукта работают по схожему принципу: колоночное СУБД с шардированием, с партиционированием данных.

И это было то еще приключение.

Киллер-фича ClickHouse конечно, экономия денег

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

Я загорелся ClickHouse на одном кейсе, когда провел тест на сжатие с новенькими кодеками: тот же DoubleDelta ужал наши полуслучайные последовательности в пять раз! И ClickHouse не смущает количество данных, если подобрать правильный ключ сортировки и степень детализации индекса в настройках MergeTree.

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

Но в то время у инструмента был большой минус высокий порог вхождения. Результат комбинации маленького на тот момент комьюнити, не сильно выходящего за пределы СНГ, фундаментальных отличий ClickHouse от обычных СУБД и невнятной документации. Приходилось проводить личные опыты: грузить в него TSBS и экспериментировать с функциями, разными версиями, настройками движков и так далее доходило даже до флагов компиляции. Драйвер существовал для галочки он использовал http-протоколы ненативно, просто обертка над Rest клиентом.

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

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

При условии, что есть миллиарды строк данных, терабайты, километры.

Компания занималась монетизацией пираток. Человек пиратил андроид-приложение, не платил за него, но видел рекламу. Для того, чтобы посчитать клиента по биллингу, посмотреть, сколько он накликал рекламы, компания начала собирать статистику. До моего прихода там были написаны собственное SDK и бэкенд. PHP принимал JSON ивент, его парсили и писали в MySQL. Никаких пулов соединений не было, пришел ивент открыли и записали.

Когда нагрузка стала расти (несколько тысяч событий в секунду), эта система перестала вывозить. Бэкенд-разработчик узнал про Hadoop, HDFS и решил его применить. Собрали кластер из нескольких машин. Идея была такой: просто пишем JSON-файлы, запихиваем в Hive. И вот уже все считается и работает.

Когда ребята начали мигрировать биллинг на Hive, поняли, что у них резко вырос чек за кластер. Все хранилось в виде несжатых JSON-файлов. К тому же HDFS и Hadoop не были заточены на риал-тайм вычисления. Приходилось планировать любую джобу заранее. Ставили на всю ночь, утром видели результат в виде огромной кучи неструктурированных данных, которые лежат прямо в тексте. И все это за деньги! Скорость никакая, запрос делать долго, на выходе свалка. Это никого не устраивало.Когда я начал выяснять, как устроена текущая архитектура проекта, то оказалось, что Spark используется в автономном режиме на нескольких узлах, что выглядело подозрительным и специфичным. Разобравшись в скрипте запуска, я понял, что текущие настройки приводили к тому, что узлы грузились на все двести, а RDD все равно читались в один поток.

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

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

И наконец мы начали добавлять запись в ClickHouse. Исходный код сервера будет достаточно понятным любому, кто знает C++. Он также иногда покрыт тестами, а если и нет, то зачастую можно найти тест, реализующий схожий кейс. Так что в итоге у нас появился свой отказоустойчивый драйвер на Scala, работавший по TCP, в бинарном Native формате, учитывающий конфигурацию кластера и позволявший нам максимально эффективно писать в несколько потоков.

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

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

Но главная проблема оказалась не в самом ClickHouse а в том, что никто не мог сходу в нем разобраться

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

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

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

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

Например, можно вспомнить раннюю поддержку UUID, когда запрос вида:

```SELECT * FROM db PREWHERE uuid != '00000000-0000-0000-0000-000000000000'```

Приводил к segfault.

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

А потом оказалось, что данные из ClickHouse слишком трудно визуализировать

Тот же Hive предлагал инструменты, которые позволяли писать запросы и делать визуализацию. Поначалу мы использовали Tabix. Это довольно примитивный клиент, он ходит напрямую в ClickHouse и отображает в браузере результат в виде таблички и простых графиков. Но в итоге взяли инструмент поинтереснее. Redash как раз выкатил бета-версию поддержки ClickHouse.

Параллельно у нас появилась часть данных на базе Redshift. В какой-то момент компания предложила брать данные из ClickHouse и перекладывать в Redshift (который, по сути, обычный SQL и можно использовать инструменты желанной визуализации). Но идея отпала сама собой я просто посчитал, сколько будет стоить кластер Redshift, который поддержит такой поток данных с ClickHouse. Мы тратили около тысячи долларов, если бы заморочились с Redshift платили бы все 30 тысяч. Поэтому продолжили работать с ClickHouse через Redash.

Но все пошло прахом, когда мы решили прикрутить к ClickHouse Tableau и в итоге влетели на 70 тысяч долларов!

Tableau это известная визуализация для баз данных. Когда мы решили это провернуть, официальной поддержки ClickHouse там не было. Зато у них была поддержка PostgreSQL. Какой-то безумец подсказал, что в PostgreSQL можно писать кастомные скрипты и протоколы форвардинга. Через питоний скрипт скрестить ClickHouse и PostgreSQL и добиться визуализации в Tableau! Это была очередная провальная идея. Данные шли только с PostgreSQL. Смысла в этом не было никакого.

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

Мы даже созвонились с продажниками из Tableau и убеждали их подружить свой продукт с новейшей российской технологией. Уже тогда было понятно, что ClickHouse потихоньку завоюет весь мир. Они лишь вежливо выслушали нас. Что забавно, недавно Tableau сделал кое-какую поддержку драйвера для ClickHouse. Не прошло и двух лет!

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

Самая большая проблема ClickHouse в нем никто не шарит. Там много подводных камней, которые нигде не описаны. Хорошая технология с плохой документацией.

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

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

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

На втором курсе после практики в одной из двух IT-компаний моего города я напросился к ним на работу. Меня взяли на зарплату в 15 тысяч рублей. Шел 2012 год, понятие девопс только зарождалось, а я начал работать помощником системного администратора. Задачи в течение дня сводились к обслуживанию Windows серверов, установке поставок, написанию инструкций и проверке того, что сделали программисты. Я крутился между серверной и институтом во вред учебе, в приоритете было удержаться на полученном месте.

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

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

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

Только к 2019 году в моей работе появилось хоть какое-то развитие. Пришел Линукс, на слуху уже был девопс. Мы стали писать микросервисы, можно было поковыряться с Docker-файлами, пособирать контейнеры из CI/CD. К тому моменту у меня прибавилось много обязанностей, навалилось командировок. Я работал свой дневной график и сидел в серверной вечерами. Паренек-сисадмин, я настолько приелся в офисе, что мое мнение никому не было интересным. Но случись любой факап крайним, конечно, становился я. Мне это совершенно не нравилось.

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

8 лет я проработал в провинциальной компании сисадмином. Потом руководство сменилось, и я стал старшим сисадмином. Понимаете?

Зарплата специалиста с 7 летним опытом и высшим образованием еле-еле дотягивала до 50 тысяч рублей. Я понятия не имел, что такое айтишная зарплата. В другом регионе в таком же провинциальном городе у меня жил знакомый. Он был моим кумиром: работал в IT, схватывал все на лету, вместо того, чтобы сменить регион на Москву, уехал в Беларусь и попал в EPAM Systems. Прошел собеседование на английском с кодингом.

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

Но я быстро понял, что мои знания в девопс не рыночные.

Мой большой опыт в индустрии сводился к винде и поверхностным знанием Docker. Работая с Ansible я больше оперировал shell-командами, нежели использовал модули. Тем не менее, набравшись смелости, я попал на собеседование. Гуру Линукса я себя не считал, но ответил на все вопросы по нему. Человек, который меня собеседовал, даже отметил, что по Линуксу у меня и правда все хорошо. Но вот стек девопса и автоматической развертки, к сожалению, был слабоват для этой вакансии.

На работе все начало надоедать. Последней каплей стала очередная задача: срочно починить кому-то клавиатуру.

Это что насмешка над трудом сисадмина, который проработал в компании столько лет? Тогда я решился, взял практикумы Ребрейна в рассрочку, и этого момента у меня закончилось свободное время. Исчезли выходные и вечера. Я много работал и параллельно осваивал курсы. Спустя три месяца я закончил Git, прошел Terraform, прокачал связку Terraform + Ansible. Понял, как пользоваться модулями, скачивать плейбуки в Ansible Galaxy. И самое главное начал все это дело хоть как-то читать и понимать. Позже я защитил практикум по Docker. Это было похоже на дипломный проект. Мне дали задание, я его сделал, потом отстаивал работоспособность, отвечал на вопросы. Параллельно я начал проходить практикум по Кубернетису. И решил, наконец, сменить работу.

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

Никакой ручной правки. Не в обиду админам будет сказано, но когда я и другие новички пытались работать руками, нам говорили: Вы что как админы? Только через Git.

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

Я расправил плечи и успешно прошел собеседование на девопса в немецкую компанию. Для этого я подтянул английский, наняв себе репетитора. По ТЗ нужно было запустить приложение в Кубернетесе, с зависимым чат-сервисом, postgresql, и чтобы базы данных хранились на хостовом пути. Правда, совмещать две работы у меня не получилось. Немцы учинили жесткий контроль за моей активностью, даже за тем, как у меня дергается мышка. Каждые 3 минуты около 15 раз скринился экран. Я подумал, что это не дело. Да и оффер, если честно, был копеечный. 7 долларов в час, около 70 тысяч рублей в месяц и вывести их было адски сложно.

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

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

На предыдущей работе все сидели и пыхтели в свой мониторы.

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

Часто вспоминаю тот день, когда решил вкладывать в свое развитие. Все произошло довольно быстро, за два года. Переломный момент попробовать учиться дистанционно. Если бы так и сидел в серверной, наверняка бы ничего не достиг. При этом у меня нет ощущения, что я потерял время. Все таки я познакомился за это время с многими интересными людьми. Тот парень из EPAM переехал в Амстердам и работает в Google Cloud. У меня бывают вопросы по работе с клиентскими облаками на гугле. Я набираю его и мы общаемся, он меня прокачивает по клауду. Я ни разу не видел этого человека вживую, но дружба с ним дала мне очень многое.

Я понимаю, если я работаю девопсом в хорошей московской компании, то и в хорошей нью-йоркской буду востребован.

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

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

В 1960-е годы Кен Томпсон легенда программирования написал компьютерную игру Space Travel для операционной системы Multics. Система была проектом компании Bell Lab, где он работал вместе с Денисом Ритчи. Позже проект закрыли, и чтобы продолжать играть в свою Space Travel, Томпсон решил портировать ее на компьютер PDP-7. Инструменты, которые он создал для порта, затем легли в основу операционной системы Unix.

Томпсон написал в одиночку первые три версии. Для Unix был нужен системный язык так появился B. Позже Денис Ритчи, коллега и друг Томпсона, подхватил разработку и написал язык C. Вот так в основе почти всего, на чем построены современные технологии, лежало желание поиграть в компьютерную игру и пет-проекты для забавы.

Кен Томпсон построил блестящую карьеру исследователя в области computer science. В середине 2000-х он устроился в Google, где вместе с Робом Пайком и Робертом Грейсмером создал Golang один из самых популярных языков последнего времени.

Go придумывали как простой язык для всего

К тому времени Google уже разрастался в гигантскую корпорацию, начинались проблемы со скоростью разработки. Там было очень много кода на C++, поддерживать его становилось все труднее. Задача, которую себе поставила компания, казалась почти наивной изобрести очень простой язык, на котором можно будет делать очень сложные вещи.

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

Кен Томпсон

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

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

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

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

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

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

* Прогноз: в течение следующих двух лет Go станет доминирующим языком для IaaS, PaaS и оркестрации.

Так и произошло почти в то же время, когда создавали язык, в IT начала стремительно развиваться культура DevOps, в которой Go почти сразу стал стандартом.

DevOps придумывали как agile для инфраструктурщиков

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

Рано или поздно ошибку устраняли (или нет), и все начиналось заново.

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

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

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

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

В то время еще не было термина Devops была только идея. Я написал в твиттере, что было бы здорово провести конференцию в Европе и обсудить саму идею. Agile System Administrators так себе название для мероприятия, поэтому мне предложили назвать его DevOpsDays с этого и началось движение Devops.

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

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

Почему Go и DevOps идеально подошли друг другу

Когда в Google начали разрабатывать Kubernetes у команды уже накопилось огромное наследие инструментов для контейнеризации. Но Кубер начали писать с нуля, поэтому встал вопрос выбора языка. Джо Беда, основной разработчик сервиса, рассказывал, что в Гугле используются многие языки не только свои разработки и они выбирали между С/С++, Java и Python.

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

Java не подошла, потому что разработчики стремились сделать установку простой на как можно более широком количестве платформ. Python откинули из-за динамической типизации.

А вот Go по словам Беды был и не слишком высокоуровневым, и не слишком низкоуровневым. Список причин, почему команда Kubernetes выбрала его, довольно широк:

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

• Быстрые инструменты. С ними мы подсели на скорость разработки, пишет Беда.

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

• Анонимные функции.

• Сборка мусора, о которой не надо задумываться.

• Строгая типизация.

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

Три основные причины

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

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

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

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

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

Что вы сами думаете про Go? Как и почему используете? Заходите к нам в сообщество там мы постоянно разбираем различные проблемы и задачи из сферы Devops, обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.