Русский
Русский
English
Статистика
Реклама

Fevlake

В IT-образовании не работают лекции. Давайте это признаем и начнем учиться правильно

02.12.2020 20:12:10 | Автор: admin
Представьте мир, где внезапно произошли две фантастические вещи родители потеряли возможность влиять на решения своих детей, полностью, абсолютно. Просто физически не могут дать им ни малейшего совета и вызвать чувство вины.

Второе в этом мире отменили армию.

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



Когда я думаю об этом, мне становится обидно. У меня есть пара друзей, которых вышвырнули из университета. Они любят говорить про это так: А знаешь, кто еще бросил вышку? Гейтс и Джобс! Сам я не враг высшему образованию, но мне не хочется с ними спорить.

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

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

Лекции не нужны


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

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

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

Но проблема не в преподавателях и не в информации проблема в самой идее лекций


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

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

В группах с обычными лекциями экзамен не сдавали, в среднем, 34% студентов, а в группах с активным обучением 22%. Средняя оценка студентов из групп активного обучения была выше почти на целый балл.



У меня создается впечатление, что, если вы посмотрите на эти данные, продолжать читать лекции просто неэтично, отозвался об исследовании физик из Гарвардского университета Эрик Мазур. Он выступает против чтения лекций уже 27 лет. Приятно видеть, как из обилия доказательств вырисовывается четкая картина чтение лекций неактуально, старомодно и неэффективно.


Лекции стали чуть ли не главной формой учебы


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

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

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

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

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

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

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


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


Мозгу нужна практика


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

Есть знаменитая история о лондонских таксистах, рассказывала об этом Ася Казанцева. Буквально несколько лет назад для того, чтобы стать настоящим таксистом в Лондоне, нужно было сдать экзамен по ориентации в городе без навигатора то есть знать как минимум две с половиной тысячи улиц, одностороннее движение, дорожные знаки, запреты на остановку, а также уметь выстроить оптимальный маршрут. Ученые сделали [таксистам] томограмму, чтобы посмотреть плотность серого вещества в гиппокампе. Это важная зона мозга, связанная с формированием памяти и пространственным мышлением. Обнаружилось, что если человек не хотел становиться таксистом или хотел, но не стал, то плотность серого вещества в его гиппокампе оставалась прежней. А вот если он хотел стать таксистом, прошел тренинг и действительно овладел новой профессией, то плотность серого вещества увеличилась на треть это очень много.

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

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

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

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

В своем исследовании биофизик Джоел Майкл из медицинского колледжа Чикаго писал: Вероятно, первым, кто указал на разницу между знать, что нечто является правдой, и тем, как что-то сделать, был Гилберт Райл в книге The Concept of Mind. Учить факты это декларативное знание, а учить, как что-то делать, процедурное. Это два абсолютно разных процесса. Если вы хотите научить студентов решать какие-либо проблемы, вам необходимо предоставить им возможность делать это на практике.

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

Например, такое исследование провел Эйдан Хорнер, психолог из университета Йорка. Он взял два одинаковых по длине текста и дал их прочитать группе испытуемых. Затем попросил перечитать первый текст еще раз, а второй постараться записать на бумагу по памяти.

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

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

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



Мозг должен конструировать знания, а не впитывать


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

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

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

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

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

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

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

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


Обучение это стихийный феномен


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

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

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

Тогда я сказал: Хорошо, я оставлю компьютер здесь на два месяца. Сделайте так, чтобы компьютер вас понимал. Они спросили: Но как? А я сказал, что не знаю, и уехал. Через два месяца, благодаря этой программе, акцент у детей почти полностью пропал и они разговаривали на идеальном английском этот факт задокументирован в журнале Information Technologies & International Development, рассказывает Митра.

С тех пор он проводил подобные эксперименты во многих городах по всему миру. Оставлял группу детей с одним компьютером, давал задание и уезжал. И каждый раз результаты были феноменальными. Например, 12-летние дети из индийской деревни самостоятельно изучили биотехнологии на английском. Они сдали тесты на проходной балл, и результаты эксперимента были опубликованы в British Journal of Educational Technology.

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

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


Нужны задачи вместо лекторов


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

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

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

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

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

В итоге, Fevlake был укомплектован спецами. Ребята, которых мы учили, уже работают лидами в нашей компании. За два года эта методология так выстрелила, что нам пришлось открывать еще одну компанию Rebrain, которая занимается чисто подготовкой DevOps-специалистов. Крупнейшие IT-компании, банки и корпорации заказывают у нас разработки подобных программ для себя и отправляют к нам своих специалистов.

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

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

05.10.2020 20:08:11 | Автор: admin


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

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

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

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

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

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

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

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

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

Мы еще не подозревали, что получили этот заказ из-за страшного недопонимания внутри их команды.


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

Все это выяснилось очень-очень болезненно. А самое обидное, это было в мой день рождения.



Пятница, вечер. Я забронировал столик в любимом винном баре и позвал корешей.

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

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

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

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

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

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

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

Остановили запись, посчитали число ивентов, которые там лежат за день. Закинули еще данных, от которых не записалась только треть. Три шарды по 2 реплики. Вставляешь 100.000 строк 33.000 не записываются.

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

Что происходило на самом деле никто не понимал.


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

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

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

До трех утра мы работали за столиком ресторана. Докидывали ивентов, insert select и погнали заполнять пробелы. Когда ты просрал данные, делается так ты берешь средние данные за предыдущие дни и вставляешь их в просранные.

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

К 6 утра я пересоздал таблицу заново, и данные начали заливаться. Все заработало без потерь.



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


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

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

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

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

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



Это была самая стремная встреча в моей карьере. Мой союзник от клиента СТО не смог найти время. На встречу я ехал к боссу и Лёне.

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

Пока поднимался, так чиркал зажигалкой, что сломал ее.

В итоге Лёни на встрече не оказалось. И мы отлично обо всем поговорили с главным! Сергей рассказал мне про свою боль. Он хотел не автоматизировать Кликхаус он хотел, чтобы запросы работали.

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

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

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

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



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

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

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

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

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

Собственно, на этом мы и расстались сделали, что смогли.



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

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

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

P.S. Так что, если у вас есть вопросы по вашей инфраструктуре, смело оставляйте заявку.

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

Я 8 лет работал сисадмином в провинции но ушел в Devops, когда меня снова попросили чинить клавиатуры

01.06.2021 18:16:36 | Автор: admin

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

На втором курсе после практики в одной из двух 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 давно поняли, что искать специалистов на рынке очень и очень трудно. Поэтому мы решили растить их сами. История Ильи только один пример. Людей с похожими историями полным полно в нашем сообществе в Телеграме одном из самых больших в сфере девопс. Заходите, там мы постоянно разбираем различные проблемы и задачи обсуждаем вещи, которые пригодятся и на собеседованиях, и в работе.

Подробнее..

Принимаем 10 000 ивентов в Яндекс.Облаке. Часть 1

23.07.2020 16:12:40 | Автор: admin
Привет всем, друзья!

* Эта статья написана по мотивам открытого практикума REBRAIN & Yandex.Cloud, если вам больше нравится смотреть видео, можете найти его по этой ссылке https://youtu.be/cZLezUm0ekE

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

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

Итак, наша история: как мы писали приложение на golang, тестировали kafka vs rabbitmq vs yqs, писали стриминг данных в Clickhouse кластер и визуализировали данные с помощью yandex datalens. Естественно, все это было приправлено инфраструктурными изысками в виде docker, terraform, gitlab ci и, конечно же, prometheus. Погнали!

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

1 часть (вы ее читаете). Мы определимся с ТЗ и архитектурой решения, а также напишем приложение на golang.
2 часть. Выливаем наше приложение на прод, делаем масштабируемым и тестируем нагрузку.
3 часть. Попробуем разобраться, зачем нам нужно хранить сообщения в буфере, а не в файлах, а также сравним между собой kafka, rabbitmq и yandex queue service.
4 часть. Будем разворачивать Clickhouse кластер, писать стриминг для перекладывания туда данных из буфера, настроим визуализацию в datalens.
5 часть. Приведем всю инфраструктуру в должный вид настроим ci/cd, используя gitlab ci, подключим мониторинг и service discovery с помощью prometheus и consul.

ТЗ


Сперва сформулируем техзадание что именно мы хотим получить на выходе.
1. Мы хотим иметь endpoint вида events.kis.im (kis.im тестовый домен, который будем использовать на протяжении всех статей), который должен принимать event-ы с помощью HTTPS.
2. События это простая jsonка вида: {event: view, os: linux, browser: chrome}. На финальном этапе мы добавим чуть больше полей, но большой роли это не сыграет. Если есть желание можно переключиться на protobuf.
3. Сервис должен уметь обрабатывать 10 000 событий в секунду.
4. Должна быть возможность масштабироваться горизонтально простым добавлением новых инстансов в наше решение. И будет неплохо, если мы сможем выносить фронт-часть в различные геолокации для уменьшения latency при запросах клиентов.
5. Отказоустойчивость. Решение должно быть достаточно стабильным и уметь выживать при падении любых частей (до определенного количества, естественно).

Архитектура


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



Итак, что у нас есть:
1. Слева изображены наши устройства, которые генерируют различные события, будь то прохождения уровня игроков в игрушке на смартфоне или создание заказа в интернет-магазине через обычный браузер. Событие, как указано в ТЗ, простой json, который отправляется на наш endpoint events.kis.im.
2. Первые два сервера простые балансировщики, их основные задачи:
  • Быть постоянно доступными. Для этого можно использовать, например, keepalived, который будет переключать виртуальный IP между нодами в случае проблем.
  • Терминировать TLS. Да, терминировать TLS мы будем именно на них. Во-первых, чтобы наше решение соответствовало ТЗ, а во-вторых, для того, чтобы снять нагрузку по установлению шифрованного соединения с наших backend серверов.
  • Балансировать входящие запросы на доступные backend сервера. Ключевое слово здесь доступные. Исходя из этого, мы приходим к пониманию, что load balancerы должны уметь мониторить наши сервера с приложениями и переставать балансировать трафик на упавшие ноды.

3. За балансировщиками у нас идут application сервера, на которых запущено достаточно простое приложение. Оно должно уметь принимать входящие запросы по HTTP, валидировать присланный json и складывать данные в буфер.
4. В качестве буфера на схеме изображена kafka, хотя, конечно, на этом уровне можно использовать и другие похожие сервисы. Kafka, rabbitmq и yqs мы сравним в третьей статье.
5. Предпоследней точкой нашей архитектуры является Clickhouse колоночная база данных, которая позволяет хранить и обрабатывать огромный объем данных. На данном уровне нам необходимо перенести данные из буфера в, собственно, систему хранения (об этом в 4 статье).

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

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



В каждой геолокации мы разворачиваем load balancer с application и kafka. В целом, достаточно 2 application сервера, 3 kafka ноды и облачного балансировщика, например, cloudflare, который будет проверять доступность нод приложения и балансировать запросы по геолокациям на основе исходного IP-адреса клиента. Таким образом данные, отправленные американским клиентом, приземлятся на американских серверах. А данные из Африки на африканских.

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

Итак, с архитектурой разобрались начинаем шатать Яндекс.Облако!

Пишем приложение


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

Потратив час времени (может, и пару часов), получаем примерно такую штуку: https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/main.go.

Какие основные моменты здесь хотелось бы отметить:
1. При старте приложения можно указать два флага. Один отвечает за порт, на котором мы будем слушать входящие http запросы (-addr). Второй за адрес kafka сервера, куда мы будем записывать наши события (-kafka):

addr     = flag.String("addr", ":8080", "TCP address to listen to")kafka    = flag.String("kafka", "127.0.0.1:9092", "Kafka endpoints)


2. Приложение использует библиотеку sarama ([] github.com/Shopify/sarama) для отправки сообщений в kafka кластер. Мы сразу выставили настройки, ориентированные на максимальную скорость обработки:

config := sarama.NewConfig()config.Producer.RequiredAcks = sarama.WaitForLocalconfig.Producer.Compression = sarama.CompressionSnappyconfig.Producer.Return.Successes = true


3. Также в наше приложение встроен клиент prometheus, который собирает различные метрики, такие как:
  • количество запросов к нашему приложению;
  • количество ошибок при выполнении запроса (невозможно прочитать post запрос, битый json, невозможно записать в кафку);
  • время обработки одного запроса от клиента, включая время записи сообщения в кафку.

4. Три endpointа, которые обрабатывает наше приложение:
  • /status просто возвращаем ok, чтобы показать, что мы живы. Хотя можно и добавить некоторые проверки, типа доступности кафка кластера.
  • /metrics по этому url prometheus client будет возвращать собранные им метрики.
  • /post основной endpoint, куда будут приходить POST запросы с json внутри. Наше приложение проверяет json на валидность и если все ок записывает данные в кафка-кластер.


Оговорюсь, что код не идеален его можно (и нужно!) допиливать. К примеру, можно отказаться от использования встроенного net/http и переключиться на более быстрый fasthttp. Или же выиграть время обработки и cpu ресурсы, вынеся проверку валидности json на более поздний этап когда данные будут перекладываться из буфера в кликхаус кластер.

Помимо разработческой стороны вопроса, мы сразу подумали о нашей будущей инфраструктуре и приняли решение разворачивать наше приложение через docker. Итоговый Dockerfile для сборки приложения https://github.com/RebrainMe/yandex-cloud-events/blob/master/app/Dockerfile. В целом, он достаточно простой, единственный момент, на который хочется обратить внимание, это multistage сборка, которая позволяет уменьшить итоговый образ нашего контейнера.

Первые шаги в облаке


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

После регистрации для вас будет создано отдельное облако и каталог default, в котором можно начать создавать облачные ресурсы. Вообще в Яндекс.Облаке взаимосвязь ресурсов выглядит следующим образом:



На один аккаунт вы можете создать несколько облаков. А внутри облака сделать разные каталоги для разных проектов компании. Подробнее об этом можно почитать в документации https://cloud.yandex.ru/docs/resource-manager/concepts/resources-hierarchy. Кстати, ниже по тексту я буду часто на нее ссылаться. Когда я настраивал всю инфраструктуру с нуля документация выручала меня не раз, так что советую поизучать.

Для управления облаком можно использовать как веб-интерфейс, так и консольную утилиту yc. Установка выполняется одной командой (для Linux и Mac Os):

curl https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash


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

Если вы хотите установить клиента для windows, то можно воспользоваться инструкцией здесь и затем выполнить yc init, чтобы полностью ее настроить:

vozerov@mba:~ $ yc initWelcome! This command will take you through the configuration process.Please go to https://oauth.yandex.ru/authorize?response_type=token&client_id= in order to obtain OAuth token.Please enter OAuth token:Please select cloud to use: [1] cloud-b1gv67ihgfu3bp (id = b1gv67ihgfu3bpt24o0q) [2] fevlake-cloud (id = b1g6bvup3toribomnh30)Please enter your numeric choice: 2Your current cloud has been set to 'fevlake-cloud' (id = b1g6bvup3toribomnh30).Please choose folder to use: [1] default (id = b1g5r6h11knotfr8vjp7) [2] Create a new folderPlease enter your numeric choice: 1Your current folder has been set to 'default' (id = b1g5r6h11knotfr8vjp7).Do you want to configure a default Compute zone? [Y/n]Which zone do you want to use as a profile default? [1] ru-central1-a [2] ru-central1-b [3] ru-central1-c [4] Don't set default zonePlease enter your numeric choice: 1Your profile default Compute zone has been set to 'ru-central1-a'.vozerov@mba:~ $


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

Если у вас несколько аккаунтов или папок внутри одного облака, можете создать дополнительные профили с отдельными настройками через yc config profile create и переключаться между ними.

Помимо вышеперечисленных способов, команда Яндекс.Облака написала очень хороший плагин для terraform для управления облачными ресурсами. Со своей стороны, я подготовил git-репозиторий, где описал все ресурсы, которые будут созданы в рамках статьи https://github.com/rebrainme/yandex-cloud-events/. Нас интересует ветка master, давайте склонируем ее себе локально:

vozerov@mba:~ $ git clone https://github.com/rebrainme/yandex-cloud-events/ eventsCloning into 'events'...remote: Enumerating objects: 100, done.remote: Counting objects: 100% (100/100), done.remote: Compressing objects: 100% (68/68), done.remote: Total 100 (delta 37), reused 89 (delta 26), pack-reused 0Receiving objects: 100% (100/100), 25.65 KiB | 168.00 KiB/s, done.Resolving deltas: 100% (37/37), done.vozerov@mba:~ $ cd events/terraform/


Все основные переменные, которые используются в terraform, прописаны в файле main.tf. Для начала работы создаем в папке terraform файл private.auto.tfvars следующего содержания:

# Yandex Cloud Oauth tokenyc_token = ""# Yandex Cloud IDyc_cloud_id = ""# Yandex Cloud folder IDyc_folder_id = ""# Default Yandex Cloud Regionyc_region = "ru-central1-a"# Cloudflare emailcf_email = ""# Cloudflare tokencf_token = ""# Cloudflare zone idcf_zone_id = ""


Все переменные можно взять из yc config list, так как консольную утилиту мы уже настроили. Советую сразу добавить private.auto.tfvars в .gitignore, чтобы ненароком не опубликовать приватные данные.

В private.auto.tfvars мы также указали данные от Cloudflare для создания dns-записей и проксирования основного домена events.kis.im на наши сервера. Если вы не хотите использовать cloudflare, то удалите инициализацию провайдера cloudflare в main.tf и файл dns.tf, который отвечает за создание необходимых dns записей.

Мы в своей работе будем комбинировать все три способа и веб-интерфейс, и консольную утилиту, и terraform.

Виртуальные сети


Честно говоря, этот шаг можно было бы и пропустить, поскольку при создании нового облака у вас автоматически создастся отдельная сеть и 3 подсети по одной на каждую зону доступности. Но все же хотелось бы сделать для нашего проекта отдельную сеть со своей адресацией. Общая схема работы сети в Яндекс.Облаке представлена на рисунке ниже (честно взята с https://cloud.yandex.ru/docs/vpc/concepts/)



Итак, вы создаете общую сеть, внутри которой ресурсы смогут общаться между собой. Для каждой зоны доступности делается подсеть со своей адресацией и подключается к общей сети. В итоге, все облачные ресурсы в ней могут общаться, даже находясь в разных зонах доступности. Ресурсы, подключенные к разным облачным сетям, могут увидеть друг друга только через внешние адреса. Кстати, как эта магия работает внутри, было хорошо описано на хабре http://personeltest.ru/aways/habr.com/en/company/yandex/blog/487694/.

Создание сети описано в файле network.tf из репозитория. Там мы создаем одну общую приватную сеть internal и подключаем к ней три подсети в разных зонах доступности internal-a (172.16.1.0/24), internal-b (172.16.2.0/24), internal-c (172.16.3.0/24).

Инициализируем terraform и создаем сети:

vozerov@mba:~/events/terraform (master) $ terraform init... skipped ..vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_vpc_subnet.internal-a -target yandex_vpc_subnet.internal-b -target yandex_vpc_subnet.internal-c... skipped ...Plan: 4 to add, 0 to change, 0 to destroy.Do you want to perform these actions?  Terraform will perform the actions described above.  Only 'yes' will be accepted to approve.  Enter a value: yesyandex_vpc_network.internal: Creating...yandex_vpc_network.internal: Creation complete after 3s [id=enp2g2rhile7gbqlbrkr]yandex_vpc_subnet.internal-a: Creating...yandex_vpc_subnet.internal-b: Creating...yandex_vpc_subnet.internal-c: Creating...yandex_vpc_subnet.internal-a: Creation complete after 6s [id=e9b1dad6mgoj2v4funog]yandex_vpc_subnet.internal-b: Creation complete after 7s [id=e2liv5i4amu52p64ac9p]yandex_vpc_subnet.internal-c: Still creating... [10s elapsed]yandex_vpc_subnet.internal-c: Creation complete after 10s [id=b0c2qhsj2vranoc9vhcq]Apply complete! Resources: 4 added, 0 changed, 0 destroyed.


Отлично! Мы сделали свою сеть и теперь готовы к созданию наших внутренних сервисов.

Создание виртуальных машин


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

Настраиваться виртуалки будут с помощью ansible, так что перед запуском terraform убедитесь, что у вас стоит одна из последних версий ансибла. И установите необходимые роли с ansible galaxy:

vozerov@mba:~/events/terraform (master) $ cd ../ansible/vozerov@mba:~/events/ansible (master) $ ansible-galaxy install -r requirements.yml- cloudalchemy-prometheus (master) is already installed, skipping.- cloudalchemy-grafana (master) is already installed, skipping.- sansible.kafka (master) is already installed, skipping.- sansible.zookeeper (master) is already installed, skipping.- geerlingguy.docker (master) is already installed, skipping.vozerov@mba:~/events/ansible (master) $


Внутри папки ansible есть пример конфигурационного файла .ansible.cfg, который использую я. Возможно, пригодится.

Перед тем, как создавать виртуалки, убедитесь, что у вас запущен ssh-agent и добавлен ssh ключик, иначе terraform не сможет подключиться к созданным машинкам. Я, конечно же, наткнулся на багу в os x: https://github.com/ansible/ansible/issues/32499#issuecomment-341578864. Чтобы у вас не повторилась такая история, перед запуском Terraform добавьте небольшую переменную в env:

vozerov@mba:~/events/terraform (master) $ export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES


В папке с терраформом создаем необходимые ресурсы:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_compute_instance.build -target yandex_compute_instance.monitoring -target yandex_compute_instance.kafkayandex_vpc_network.internal: Refreshing state... [id=enp2g2rhile7gbqlbrkr]data.yandex_compute_image.ubuntu_image: Refreshing state...yandex_vpc_subnet.internal-a: Refreshing state... [id=e9b1dad6mgoj2v4funog]An execution plan has been generated and is shown below.Resource actions are indicated with the following symbols:  + create... skipped ...Plan: 3 to add, 0 to change, 0 to destroy.... skipped ...


Если все завершилось удачно (а так и должно быть), то у нас появятся три виртуальные машины:
  1. build машинка для тестирования и сборки приложения. Docker был установлен автоматически ansibleом.
  2. monitoring машинка для мониторинга на нее установлен prometheus & grafana. Логин / пароль стандартный: admin / admin
  3. kafka небольшая машинка с установленной kafka, доступная по порту 9092.


Убедимся, что все они на месте:

vozerov@mba:~/events (master) $ yc compute instance list+----------------------+------------+---------------+---------+---------------+-------------+|          ID          |    NAME    |    ZONE ID    | STATUS  |  EXTERNAL IP  | INTERNAL IP |+----------------------+------------+---------------+---------+---------------+-------------+| fhm081u8bkbqf1pa5kgj | monitoring | ru-central1-a | RUNNING | 84.201.159.71 | 172.16.1.35 || fhmf37k03oobgu9jmd7p | kafka      | ru-central1-a | RUNNING | 84.201.173.41 | 172.16.1.31 || fhmt9pl1i8sf7ga6flgp | build      | ru-central1-a | RUNNING | 84.201.132.3  | 172.16.1.26 |+----------------------+------------+---------------+---------+---------------+-------------+


Ресурсы на месте, и отсюда можем вытащить их ip-адреса. Везде далее я буду использовать ip-адреса для подключения по ssh и тестирования приложения. Если у вас есть аккаунт на cloudflare, подключенный к terraform, смело используйте свежесозданные DNS-имена.
Кстати, при создании виртуалке выдается внутренний ip и внутреннее DNS-имя, так что обращаться к серверам внутри сети можно по именам:

ubuntu@build:~$ ping kafka.ru-central1.internalPING kafka.ru-central1.internal (172.16.1.31) 56(84) bytes of data.64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=1 ttl=63 time=1.23 ms64 bytes from kafka.ru-central1.internal (172.16.1.31): icmp_seq=2 ttl=63 time=0.625 ms^C--- kafka.ru-central1.internal ping statistics ---2 packets transmitted, 2 received, 0% packet loss, time 1001msrtt min/avg/max/mdev = 0.625/0.931/1.238/0.308 ms


Это нам пригодится для указания приложению endpointа с kafkой.

Собираем приложение


Отлично, сервачки есть, приложение есть осталось только его собрать и опубликовать. Для сборки будем использовать обычный docker build, а вот в качестве хранилища образов возьмем сервис от яндекса container registry. Но обо всем по порядку.

Копируем на build машинку приложение, заходим по ssh и собираем образ:

vozerov@mba:~/events/terraform (master) $ cd ..vozerov@mba:~/events (master) $ rsync -av app/ ubuntu@84.201.132.3:app/... skipped ...sent 3849 bytes  received 70 bytes  7838.00 bytes/sectotal size is 3644  speedup is 0.93vozerov@mba:~/events (master) $ ssh 84.201.132.3 -l ubuntuubuntu@build:~$ cd appubuntu@build:~/app$ sudo docker build -t app .Sending build context to Docker daemon  6.144kBStep 1/9 : FROM golang:latest AS build... skipped ...Successfully built 9760afd8ef65Successfully tagged app:latest


Полдела сделано теперь можно проверить работоспособность нашего приложения, запустив его и направив на kafka:

ubuntu@build:~/app$ sudo docker run --name app -d -p 8080:8080 app /app/app -kafka=kafka.ru-central1.internal:9092</code>С локальной машинки можно отправить тестовый event и посмотреть на ответ:<code>vozerov@mba:~/events (master) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://84.201.132.3:8080/postHTTP/1.1 200 OKContent-Type: application/jsonDate: Mon, 13 Apr 2020 13:53:54 GMTContent-Length: 41{"status":"ok","partition":0,"Offset":0}vozerov@mba:~/events (master) $


Приложение ответило успехом записи и указанием id партиции и оффсета, в который попало сообщение. Дело за малым создать registry в Яндекс.Облаке и закинуть туда наш образ (как это сделать при помощи трех строчек, описано в registry.tf файле). Создаем хранилище:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_container_registry.events... skipped ...Plan: 1 to add, 0 to change, 0 to destroy.... skipped ...Apply complete! Resources: 1 added, 0 changed, 0 destroyed.


Для аутентификации в container registry есть несколько способов с помощью oauth токена, iam токена или ключа сервисного аккаунта. Более подробно об этих способах в документации https://cloud.yandex.ru/docs/container-registry/operations/authentication. Мы будем использовать ключ сервисного аккаунта, поэтому создаем аккаунт:

vozerov@mba:~/events/terraform (master) $ terraform apply -target yandex_iam_service_account.docker -target yandex_resourcemanager_folder_iam_binding.puller -target yandex_resourcemanager_folder_iam_binding.pusher... skipped ...Apply complete! Resources: 3 added, 0 changed, 0 destroyed.


Теперь осталось сделать для него ключик:

vozerov@mba:~/events/terraform (master) $ yc iam key create --service-account-name docker -o key.jsonid: ajej8a06kdfbehbrh91pservice_account_id: ajep6d38k895srp9osijcreated_at: "2020-04-13T14:00:30Z"key_algorithm: RSA_2048


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

vozerov@mba:~/events/terraform (master) $ scp key.json ubuntu@84.201.132.3:key.json                                                                                                                    100% 2392   215.1KB/s   00:00vozerov@mba:~/events/terraform (master) $ ssh 84.201.132.3 -l ubuntuubuntu@build:~$ cat key.json | sudo docker login --username json_key --password-stdin cr.yandexWARNING! Your password will be stored unencrypted in /home/ubuntu/.docker/config.json.Configure a credential helper to remove this warning. Seehttps://docs.docker.com/engine/reference/commandline/login/#credentials-storeLogin Succeededubuntu@build:~$


Для загрузки образа в реестр нам понадобится ID container registry, берем его из утилиты yc:

vozerov@mba:~ $ yc container registry get eventsid: crpdgj6c9umdhgaqjfmmfolder_id:name: eventsstatus: ACTIVEcreated_at: "2020-04-13T13:56:41.914Z"


После этого тегируем наш образ новым именем и загружаем:

ubuntu@build:~$ sudo docker tag app cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1ubuntu@build:~$ sudo docker push cr.yandex/crpdgj6c9umdhgaqjfmm/events:v1The push refers to repository [cr.yandex/crpdgj6c9umdhgaqjfmm/events]8c286e154c6e: Pushed477c318b05cb: Pushedbeee9f30bc1f: Pushedv1: digest: sha256:1dd5aaa9dbdde2f60d833be0bed1c352724be3ea3158bcac3cdee41d47c5e380 size: 946


Можем убедиться, что образ успешно загрузился:

vozerov@mba:~/events/terraform (master) $ yc container repository list+----------------------+-----------------------------+|          ID          |            NAME             |+----------------------+-----------------------------+| crpe8mqtrgmuq07accvn | crpdgj6c9umdhgaqjfmm/events |+----------------------+-----------------------------+


Кстати, если вы установите утилиту yc на машинку с linux, то можете использовать команду
yc container registry configure-docker
для настройки докера.

Заключение


Мы проделали большую и трудную работу и в результате:
  1. Придумали архитектуру нашего будущего сервиса.
  2. Написали приложение на golang, которое реализует нашу бизнес-логику.
  3. Собрали его и вылили в приватный container registry.


В следующей части перейдем к интересному выльем наше приложение в production и наконец запустим на него нагрузку. Не переключайтесь!

Этот материал есть в видеозаписи открытого практикума REBRAIN & Yandex.Cloud: Принимаем 10 000 запросов в секунду на Яндекс Облако https://youtu.be/cZLezUm0ekE


Если вам интересно посещать такие мероприятия онлайн и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN https://rebrainme.com/channel

Отдельное спасибо хотим сказать Yandex.Cloud за возможность проведения такого мерпориятия. Ссылочка на них https://cloud.yandex.ru/prices

Если вам нужен переезд в облако или есть вопросы по вашей инфраструктуре, смело оставляйте заявку https://fevlake.com

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

Принимаем 10 000 ивентов в Яндекс.Облаке. Часть 2

28.07.2020 12:21:05 | Автор: admin
И снова здравствуйте! Продолжаем нашу серию статей про то, как мы щупали Яндекс.Облако.

Давайте вспомним план, по которому мы с вами двигаемся:
1 часть. Мы определились с ТЗ и архитектурой решения, написали приложение на golang.
2 часть (вы сейчас здесь). Выливаем наше приложение на прод, делаем масштабируемым и тестируем нагрузку.
3 часть. Попробуем разобраться, зачем нам нужно хранить сообщения в буфере, а не в файлах, а также сравним между собой kafka, rabbitmq и yandex queue service.
4 часть. Будем разворачивать Clickhouse кластер, писать стриминг для перекладывания туда данных из буфера, настроим визуализацию в datalens.
5 часть. Приведем всю инфраструктуру в должный вид настроим ci/cd, используя gitlab ci, подключим мониторинг и service discovery с помощью consul и prometheus.



Ну что, переходим к нашим задачкам.

Выливаемся в production


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

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

Для масштабирования мы будем использовать группы машин (instance groups), доступные в compute cloud. Они позволяют создавать виртуалки по шаблону, следить за их доступностью с помощью health checkов, а также автоматически увеличивать количество узлов в случае возрастания нагрузки. Подробнее здесь: https://cloud.yandex.ru/docs/compute/concepts/instance-groups/

Встает только один вопрос какой шаблон использовать для виртуальной машины? Конечно, можно установить linux, настроить его, сделать образ и залить в хранилище образов в Яндекс.Облаке. Но для нас это долгий и непростой путь. В процессе рассмотрения различных образов, доступных при создании виртуалки, мы наткнулись на интересный экземпляр container optimized image (https://cloud.yandex.ru/docs/cos/concepts/). Он позволяет запустить один docker контейнер в сетевом режиме host. То есть при создании виртуалки указывается примерно такая спецификация для образа container optimized image:
spec:  containers:    - name: api      image: vozerov/events-api:v1      command:        - /app/app      args:        - -kafka=kafka.ru-central1.internal:9092      securityContext:        privileged: false      tty: false      stdin: false      restartPolicy: Always

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

Схема вырисовывается вполне интересная:

  1. Мы создаем instance group с автоматическим масштабированием при превышении 60% cpu usage.
  2. В качестве шаблона указываем виртуальную машину с образом container optimized image и параметрами для запуска нашего Docker-контейнера.
  3. Создаем load balancer, который будет смотреть на нашу instance group и автоматически обновляться при добавлении или удалении виртуальных машин.
  4. Приложение будет мониториться и как instance group, и самим балансировщиком, который выкинет недоступные виртуалки из балансировки.

Звучит как план!

Попробуем создать instance group с помощью terraform. Все описание лежит в instance-group.tf, прокомментирую основные моменты:
  1. service account id будет использоваться для создания и удаления виртуалок. Кстати, нам его придется создать.
    service_account_id = yandex_iam_service_account.instances.id
    
  2. Данные для указания спецификации контейнера вынесены в отдельный файл spec.yml, где помимо прочего указывается образ, который необходимо запустить. Поскольку внутренний registry у нас появился во время написания данной статьи, а гит-репозиторий я выложил в паблик на гитхаб на данный момент там прописан образ с публичного docker hub. Чтобы использовать образ из нашего репозитория, достаточно прописать путь до него
                metadata = {  docker-container-declaration = file("spec.yml")  ssh-keys = "ubuntu:${file("~/.ssh/id_rsa.pub")}"}
    
  3. Укажем еще один service account id, он будет использоваться образом container optimized image, чтобы пройти аутентификацию в container registry и скачать образ нашего приложения. Сервисный аккаунт с доступом к registry мы уже создавали, поэтому будем использовать его:

    service_account_id = yandex_iam_service_account.docker.id
    
  4. Scale policy. Самая интересная часть:
    autoscale {  initialsize = 3  measurementduration = 60  cpuutilizationtarget = 60  minzonesize = 1  maxsize = 6  warmupduration = 60  stabilizationduration = 180}
    

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

    Основные параметры такие:
    initial size первоначальный размер группы;
    measurement_duration период изменения целевого показателя;
    cpu_utilization_target целевое значение показателя, при большем значении которого надо расширить группу;
    min_zone_size минимальное количество нод в одной зоне доступности планировщик не будет удалять ноды, чтобы их количество стало ниже этого значения;
    max_size максимальное количество нод в группе;
    warmup_duration период прогрева, в течение которого планировщик не будет брать значения метрик с данной ноды, а будет использовать среднее значение в группе;
    stabilization_duration период стабилизации после увеличения количества нод в группе в течение указанного промежутка времени балансировщик не будет удалять созданные машины, даже если целевой показатель опустился ниже порогового значения.

    Теперь простыми словами о наших параметрах. На начальном этапе создаем 3 машинки (initial_size), минимум по одной в каждой зоне доступности (min_zone_size). Измеряем показатель cpu раз в минуту на всех машинках (measurement_duration). Если среднее значение превышает 60% (cpu_utilization_target), то создаем новые виртуалки, но не больше шести (max_size). После создания в течение 60 секунд не собираем метрики с новой машинки (warmup_duration), поскольку во время старта она может использовать достаточно много cpu. А 120 секунд после создания новой машинки не удаляем ничего (stabilization_duration), даже если среднее значение метрик в группе стало ниже 60% (cpu_utilization_target).

    Подробнее о масштабировании https://cloud.yandex.ru/docs/compute/concepts/instance-groups/policies#auto-scale-policy
  5. Allocation policy. Указывает, в каких зонах доступности создавать наши виртуальные машины, используем все три доступных зоны.

     allocationpolicy {  zones = ["ru-central1-a", "ru-central1-b", "ru-central1-c"]}
    
  6. Политика деплоя машинок:
    deploy_policy {  maxunavailable = 1  maxcreating = 1  maxexpansion = 1  maxdeleting = 1}
    


    max_creating максимальное число одновременно создаваемых машин;
    max_deleting максимальное число одновременно удаляемых машин;
    max_expansion на какое число виртуалок можно превысить размер группы при обновлении;
    max_unavailable максимальное число виртуалок в статусе RUNNING, которые могут быть удалены;

    Подробнее о параметрах https://cloud.yandex.ru/docs/compute/concepts/instance-groups/policies#deploy-policy
  7. Настройки балансировщика:
     load_balancer {  target_group_name = "events-api-tg"}
    

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


Вроде все основное прописали давайте создавать сервисный аккаунт для instance group и, собственно, саму группу.
vozerov@mba:~/events/terraform (master *) $ terraform apply -target yandex_iam_service_account.instances -target yandex_resourcemanager_folder_iam_binding.editor... skipped ...Apply complete! Resources: 2 added, 0 changed, 0 destroyed.vozerov@mba:~/events/terraform (master *) $ terraform apply -target yandex_compute_instance_group.events_api_ig... skipped ...Apply complete! Resources: 1 added, 0 changed, 0 destroyed.


Группа создалась можно посмотреть и проверить:
vozerov@mba:~/events/terraform (master *) $ yc compute instance-group list+----------------------+---------------+------+|          ID          |     NAME      | SIZE |+----------------------+---------------+------+| cl1s2tu8siei464pv1pn | events-api-ig |    3 |+----------------------+---------------+------+vozerov@mba:~/events/terraform (master *) $ yc compute instance list+----------------------+---------------------------+---------------+---------+----------------+-------------+|          ID          |           NAME            |    ZONE ID    | STATUS  |  EXTERNAL IP   | INTERNAL IP |+----------------------+---------------------------+---------------+---------+----------------+-------------+| ef3huodj8g4gc6afl0jg | cl1s2tu8siei464pv1pn-ocih | ru-central1-c | RUNNING | 130.193.44.106 | 172.16.3.3  || epdli4s24on2ceel46sr | cl1s2tu8siei464pv1pn-ipym | ru-central1-b | RUNNING | 84.201.164.196 | 172.16.2.31 || fhmf37k03oobgu9jmd7p | kafka                     | ru-central1-a | RUNNING | 84.201.173.41  | 172.16.1.31 || fhmh4la5dj0m82ihoskd | cl1s2tu8siei464pv1pn-ahuj | ru-central1-a | RUNNING | 130.193.37.94  | 172.16.1.37 || fhmr401mknb8omfnlrc0 | monitoring                | ru-central1-a | RUNNING | 84.201.159.71  | 172.16.1.14 || fhmt9pl1i8sf7ga6flgp | build                     | ru-central1-a | RUNNING | 84.201.132.3   | 172.16.1.26 |+----------------------+---------------------------+---------------+---------+----------------+-------------+vozerov@mba:~/events/terraform (master *) $

Три ноды с кривыми именами это наша группа. Проверяем, что приложения на них доступны:
vozerov@mba:~/events/terraform (master *) $ curl -D - -s http://130.193.44.106:8080/statusHTTP/1.1 200 OKDate: Mon, 13 Apr 2020 16:32:04 GMTContent-Length: 3Content-Type: text/plain; charset=utf-8okvozerov@mba:~/events/terraform (master *) $ curl -D - -s http://84.201.164.196:8080/statusHTTP/1.1 200 OKDate: Mon, 13 Apr 2020 16:32:09 GMTContent-Length: 3Content-Type: text/plain; charset=utf-8okvozerov@mba:~/events/terraform (master *) $ curl -D - -s http://130.193.37.94:8080/statusHTTP/1.1 200 OKDate: Mon, 13 Apr 2020 16:32:15 GMTContent-Length: 3Content-Type: text/plain; charset=utf-8okvozerov@mba:~/events/terraform (master *) $

К слову, можно зайти на виртуалки с логином ubuntu и посмотреть логи контейнера и как он запущен.

Для балансировщика также создалась целевая группа, на которую можно отправлять запросы:
vozerov@mba:~/events/terraform (master *) $ yc load-balancer target-group list+----------------------+---------------+---------------------+-------------+--------------+|          ID          |     NAME      |       CREATED       |  REGION ID  | TARGET COUNT |+----------------------+---------------+---------------------+-------------+--------------+| b7rhh6d4assoqrvqfr9g | events-api-tg | 2020-04-13 16:23:53 | ru-central1 |            3 |+----------------------+---------------+---------------------+-------------+--------------+vozerov@mba:~/events/terraform (master *) $

Давайте уже создадим балансировщик и попробуем пустить на него трафик! Этот процесс описан в load-balancer.tf, ключевые моменты:
  1. Указываем, какой внешний порт будет слушать балансировщик и на какой порт отправлять запрос к виртуальным машинам. Указываем тип внешнего адреса ip v4. На данный момент балансировщик работает на транспортном уровне, поэтому балансировать он может только tcp / udp соединения. Так что прикручивать ssl придется либо на своих виртуалках, либо на внешнем сервисе, который умеет https, например, cloudflare.
     listener {  name = "events-api-listener"  port = 80  target_port = 8080  external_address_spec {    ipversion = "ipv4"  }}
    
  2. healthcheck {  name = "http"  http_options {    port = 8080    path = "/status"  }        }
    



    Healthchecks. Здесь мы указываем параметры проверки наших узлов проверяем по http url /status на порту 8080. Если проверка будет провалена, то машинка будет выкинута из балансировки.
    Подробнее про балансировщик нагрузки cloud.yandex.ru/docs/load-balancer/concepts. Из интересного вы можете подключить услугу защиты от DDOS на балансировщике. Тогда на ваши сервера будет приходить уже очищенный трафик.

Создаем:
vozerov@mba:~/events/terraform (master *) $ terraform apply -target yandex_lb_network_load_balancer.events_api_lb... skipped ...Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Вытаскиваем ip созданного балансировщика и тестируем работу:
vozerov@mba:~/events/terraform (master *) $ yc load-balancer network-load-balancer get events-api-lbid:folder_id:created_at: "2020-04-13T16:34:28Z"name: events-api-lbregion_id: ru-central1status: ACTIVEtype: EXTERNALlisteners:- name: events-api-listener  address: 130.193.37.103  port: "80"  protocol: TCP  target_port: "8080"attached_target_groups:- target_group_id:  health_checks:  - name: http    interval: 2s    timeout: 1s    unhealthy_threshold: "2"    healthy_threshold: "2"    http_options:      port: "8080"      path: /status

Теперь можем покидать в него сообщения:
vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://130.193.37.103/postHTTP/1.1 200 OKContent-Type: application/jsonDate: Mon, 13 Apr 2020 16:42:57 GMTContent-Length: 41{"status":"ok","partition":0,"Offset":1}vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://130.193.37.103/postHTTP/1.1 200 OKContent-Type: application/jsonDate: Mon, 13 Apr 2020 16:42:58 GMTContent-Length: 41{"status":"ok","partition":0,"Offset":2}vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' http://130.193.37.103/postHTTP/1.1 200 OKContent-Type: application/jsonDate: Mon, 13 Apr 2020 16:43:00 GMTContent-Length: 41{"status":"ok","partition":0,"Offset":3}vozerov@mba:~/events/terraform (master *) $

Отлично, все работает. Остался последний штрих, чтобы мы были доступны по https подключим cloudflare с проксированием. Если вы решили обойтись без cloudflare, можете пропустить данный шаг.
vozerov@mba:~/events/terraform (master *) $ terraform apply -target cloudflare_record.events... skipped ...Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Тестируем через HTTPS:
vozerov@mba:~/events/terraform (master *) $ curl -D - -s -X POST -d '{"key1":"data1"}' https://events.kis.im/postHTTP/2 200date: Mon, 13 Apr 2020 16:45:01 GMTcontent-type: application/jsoncontent-length: 41set-cookie: __cfduid=d7583eb5f791cd3c1bdd7ce2940c8a7981586796301; expires=Wed, 13-May-20 16:45:01 GMT; path=/; domain=.kis.im; HttpOnly; SameSite=Laxcf-cache-status: DYNAMICexpect-ct: max-age=604800, report-uri="http://personeltest.ru/aways/report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"server: cloudflarecf-ray: 5836a7b1bb037b2b-DME{"status":"ok","partition":0,"Offset":5}vozerov@mba:~/events/terraform (master *) $

Все наконец-то работает.

Тестируем нагрузку


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

Перед запуском тестирования стоит сделать одну простую штуку добавить наши application ноды в prometheus, чтобы следить за количеством запросов и временем обработки одного запроса. Поскольку мы пока не добавляли никакого service discovery (мы сделаем это в 5 статье серии), просто пропишем static_configs на нашем monitoring сервере. Узнать его ip можно стандартным способом через yc compute instance list, после чего дописать в /etc/prometheus/prometheus.yml следующие настройки:
  - job_name: api    metrics_path: /metrics    static_configs:    - targets:      - 172.16.3.3:8080      - 172.16.2.31:8080      - 172.16.1.37:8080

IP-адреса наших машинок также можно взять из yc compute instance list. Рестартуем prometheus через systemctl restart prometheus и проверяем, что ноды успешно опрашиваются, зайдя в веб-интерфейс, доступный на порту 9090 (84.201.159.71:9090).

Давайте еще добавим дашборд в графану из папки grafana. Заходим в Grafana по порту 3000 (84.201.159.71:3000) и с логином / паролем admin / Password. Далее добавляем локальный prometheus и импортируем dashboard. Собственно, на этом моменте подготовка завершена можно закидывать нашу инсталляцию запросами.

Для тестирования будем использовать yandex tank (https://yandex.ru/dev/tank/) с плагином для overload.yandex.net, который позволит нам визуализировать данные, полученные танком. Все необходимое для работы находится в папке load изначального гит-репозитория.

Немного о том, что там есть:
  1. token.txt файл с API ключиком от overload.yandex.net его можно получить, зарегистрировавшись на сервисе.
  2. load.yml конфигурационный файл для танка, там прописан домен для тестирования events.kis.im, тип нагрузки rps и количество запросов 15 000 в секунду в течение 3-х минут.
  3. data специальный файл для генерации конфига в формате ammo.txt. В нем прописываем тип запроса, url, группу для отображения статистики и собственно данные, которые необходимо отправлять.
  4. makeammo.py скрипт для генерации ammo.txt файла из data-файла. Подробнее про скрипт yandextank.readthedocs.io/en/latest/ammo_generators.html
  5. ammo.txt итоговый ammo файл, который будет использоваться для отправки запросов.

Для тестирования я взял виртуалку за пределами Яндекс.Облака (чтобы все было честно) и создал ей DNS запись load.kis.im. Накатил туда docker, поскольку танк мы будем запускать, используя образ https://hub.docker.com/r/direvius/yandex-tank/.

Ну что же, приступаем. Копируем нашу папку на сервер, добавляем токен и запускаем танк:
vozerov@mba:~/events (master *) $ rsync -av load/ cloud-user@load.kis.im:load/... skipped ...sent 2195 bytes  received 136 bytes  1554.00 bytes/sectotal size is 1810  speedup is 0.78vozerov@mba:~/events (master *) $ ssh load.kis.im -l cloud-usercloud-user@load:~$ cd load/cloud-user@load:~/load$ echo "TOKEN" > token.txtcloud-user@load:~/load$ sudo docker run -v $(pwd):/var/loadtest --net host --rm -it direvius/yandex-tank -c load.yaml ammo.txtNo handlers could be found for logger "netort.resource"17:25:25 [INFO] New test id 2020-04-13_17-25-25.35549017:25:25 [INFO] Logging handler <logging.StreamHandler object at 0x7f209a266850> added17:25:25 [INFO] Logging handler <logging.StreamHandler object at 0x7f209a20aa50> added17:25:25 [INFO] Created a folder for the test. /var/loadtest/logs/2020-04-13_17-25-25.35549017:25:25 [INFO] Configuring plugins...17:25:25 [INFO] Loading plugins...17:25:25 [INFO] Testing connection to resolved address 104.27.164.45 and port 8017:25:25 [INFO] Resolved events.kis.im into 104.27.164.45:8017:25:25 [INFO] Configuring StepperWrapper...17:25:25 [INFO] Making stpd-file: /var/loadtest/ammo.stpd17:25:25 [INFO] Default ammo type ('phantom') used, use 'phantom.ammo_type' option to override it... skipped ...

Все, процесс запущен. В консоли это выглядит примерно так:



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



Как можно заметить наши ноды не догрузились даже до 50% CPU, поэтому тест с автомасштабированием придется повторить. А пока глянем на время обработки запроса в Grafana:



Количество запросов порядка 3000 на одну ноду немного до 10 000 не догрузили. Время ответа радует порядка 11 ms на запрос. Единственный, кто выделяется, 172.16.1.37 у него время обработки запроса в два раза меньше. Но это и логично он находится в той же зоне доступности ru-central1-a, что и kafka, которая сохраняет сообщения.

Кстати, отчет по первому запуску доступен по ссылке: https://overload.yandex.net/265967.

Итак, давайте запустим тест повеселее добавим параметр instances: 2000, чтобы добиться 15 000 запросов в секунду, и увеличим время теста до 10 минут. Итоговый файл будет выглядеть так:
overload:  enabled: true  package: yandextank.plugins.DataUploader  token_file: "token.txt"phantom:  address: 130.193.37.103  load_profile:    load_type: rps    schedule: const(15000, 10m)  instances: 2000console:  enabled: truetelegraf:  enabled: false

Внимательный читатель обратит внимание, что я поменял адрес на IP балансировщика связано это с тем, что cloudflare начал меня блочить за огромное количество запросов с одного ip. Пришлось натравить tank напрямую на балансер Яндекс.Облака. После запуска можно наблюдать такую картину:



Использование CPU выросло, и планировщик принял решение увеличить количество нод в зоне B, что и сделал. Это можно увидеть по логам instance group:
vozerov@mba:~/events/load (master *) $ yc compute instance-group list-logs events-api-ig2020-04-13 18:26:47    cl1s2tu8siei464pv1pn-ejok.ru-central1.internal  1m AWAITING_WARMUP_DURATION -> RUNNING_ACTUAL2020-04-13 18:25:47    cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 37s OPENING_TRAFFIC -> AWAITING_WARMUP_DURATION2020-04-13 18:25:09    cl1s2tu8siei464pv1pn-ejok.ru-central1.internal 43s CREATING_INSTANCE -> OPENING_TRAFFIC2020-04-13 18:24:26    cl1s2tu8siei464pv1pn-ejok.ru-central1.internal  6s DELETED  -> CREATING_INSTANCE2020-04-13 18:24:19    cl1s2tu8siei464pv1pn-ozix.ru-central1.internal  0s PREPARING_RESOURCES -> DELETED2020-04-13 18:24:19    cl1s2tu8siei464pv1pn-ejok.ru-central1.internal  0s PREPARING_RESOURCES -> DELETED2020-04-13 18:24:15    Target allocation changed in accordance with auto scale policy in zone ru-central1-a: 1 -> 22020-04-13 18:24:15    Target allocation changed in accordance with auto scale policy in zone ru-central1-b: 1 -> 2... skipped ...2020-04-13 16:23:57    Balancer target group b7rhh6d4assoqrvqfr9g created2020-04-13 16:23:43    Going to create balancer target group

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

Заключение


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

  1. Подняли мониторинг и кафку.
  2. Создали группу виртуалок с автомасштабированием, на которых запускается наше приложение.
  3. Подвязали к load balancerу cloudflare для использования ssl сертификатов.

В следующий раз займемся сравнением и тестированием rabbitmq / kafka / yandex queue service. Stay tuned!
*Этот материал есть в видеозаписи открытого практикума REBRAIN & Yandex.Cloud: Принимаем 10 000 запросов в секунду на Яндекс Облако https://youtu.be/cZLezUm0ekE

Если вам интересно посещать такие мероприятия онлайн и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN.

Отдельное спасибо хотим сказать Yandex.Cloud за возможность проведения такого мерпориятия. Ссылочка на них https://cloud.yandex.ru/prices

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

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

Я занялся преподаванием и не бросил работу. Совмещать офигенно

02.11.2020 18:18:10 | Автор: admin


В 11 классе я пошел на курсы для сертификации CISCO. Я, как всегда и везде, был самый молодой в группе. Вокруг сидели дядьки руководители IT-отделов, а мне было 16 лет.

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

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

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

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

Но соль в том, что поехать и сдать CCIE не смог ни тот, ни другой.



Вот я и думал, что сочетать невозможно


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

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

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

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

В 2018 году мы начали проводить первые вебинары и постоянно собачились.

Я продалбывал все сроки, потому что очень боялся выступать хотя меня слушали всего 10-15 человек


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

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

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



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

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


И один их первых нафига?

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

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

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

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

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

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

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



Мои проблемы начались не из-за времени и сил. Беда была в другом:

Основной груз преподавания в ответственности


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

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

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

То, что преподавание тормозит твое развитие как профессионала это полная чушь


Вранье чистой воды.

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

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

То есть, я взял и прокачался просто потому, что готовился к выступлению


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

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

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

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

Ты всегда отвечаешь на вопросы и знаешь ответы.

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

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

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

Ты, сам того не заметив, становишься известным в профессиональных кругах


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

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



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

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

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


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

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

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



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

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

Ультимативный гайд по собеседованию DevOps-инженеров что спрашивать и к чему готовиться

12.11.2020 20:10:42 | Автор: admin


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

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

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

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


Сперва я быстро просматриваю все резюме


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

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

В быстром отборе резюме помогает правило: чем больше технологий я встречаю, тем лучше. Если у человека в резюме написано MySQL, Linux, Postgres, Apache и так далее шансы есть. Человек по крайней мере слышал о технологиях и, кто знает, возможно, даже сам с ними работал. Хотя будем честны в резюме можно написать все, что угодно.

На собеседовании первым делом проверяю базу


Когда я стану немощным стариком и меня будет стремно бить в ответ, я начну колотить палкой по спине всех, кто не знает сети! Это маст хэв для любого инженера. Мы живем в мире, где все происходит в сетях. Даже в закрытом госсекторе найдется локальный контур. И там сидит разработчик, который пишет какой-нибудь proxy-сервис или сочиняет сервис, работающий с API-шкой, и ничего не понимает в API.

Я не требую особых знаний, я не прошу настроить мне MPLS. Но что такое маска подсети, что такое IP-адрес в 21 веке должны знать все IT-специалисты. Я понятия не имею, что у человека в голове происходит, когда он не понимает, что такое 127.0.0.1. Он сидит на локальной машине, у него запущен сервис на виртуалке. У сервиса прописан эндпоинт 127.0.0.1, коннект к базе. От незнания наш герой вхреначивает то же самое. Как результат: у меня не коннектится к базе. Конечно, блин, не коннектится!

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


Вот, например, стандартная задачка из CCNA, на понимание того, как работают сети


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

Что происходит в этот момент?
Мне важно услышать нечто в духе: Ага, смотрим таблицу маршрутизации, видим, что до этой сети можно попасть через роутер. Компьютер отправляет запрос в сеть, пытается найти, определить MAC-адрес по айпишнику у этого роутера, передает ему данные. Роутер видит, сетка подключена, отдает данные компьютеру Б. Компьютер Б принимает их, хеппи энд.



Затем я спрашиваю по всем уровням модели OSI


Слышал ли что-нибудь человек про Spanning Tree протокол? Про корневой протокол, про IP-уровень? Хорошо, а как это все работает? Понимает ли он, как происходит роутинг? Ну и скопом: таблицы маршрутизации, динамический протокол маршрутизации, транспортный уровень TCP. И так далее, и так далее.

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

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

Задаю вопросы про DNS


Какие бывают типы записи? Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.

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

Абсолютно везде сейчас используется HTTP-протокол, и я про него спрашиваю


Я начинаю со стандартных вопросов об отличиях http-версий 1.0, 1.1 и второй версии. Интересуюсь, что такое headers и зачем они нужны. Как веб-сервер понимает, что ему пришел запрос на определенный virtual host, а не на любой другой. И всегда задаю пару вопросов по Nginx.

Дальше плавно переключаю внимание на TLS-протокол


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

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

Ответ под спойлером
Дело в том, что сначала устанавливается TLS-соединение, а потом уже следом идет HTTP-протокол, а веб-сервер может определить, к какому сайту обращается клиент только по HTTP-протоколу, по хедеру хоста. Nginx еще не знает, к какому сайту обратились, но он уже должен отдать сертификат клиенту. Есть расширения для TLS-протокола, которые позволяют клиенту передать хостнейм серверу, к которому он обращается при попытке установить TLS-соединение. И таким образом выбирать нужный сертификат. Когда этого расширения не было, на одном IP-шнике можно было держать только один сайт с включенным SSL.

Перехожу к Linux и BASH


Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.

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

По Linux спрошу, как заменить в файле строчки другими строчками. Или как распарсить какой-нибудь access.log в Nginx средствами BASH. Чтобы человек рассказал про awk, про cat, про sort, про все, что помогает быстрой работе.

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

Потом надо выяснить, как дела с виртуализацией


Обычная виртуализация, виртуализация через гипервизор. Если кандидат заводит разговор про паравиртуализацию значит, что-то знает.

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

Перемещаемся к контейнерам


Узнаю, работал ли собеседник с Docker? Собирал ли он образы, писал ли Docker-файлы, использовал ли Docker compose, деплоил ли с его помощью. Зачем вообще нужны эти контейнеры и как они работают? Поднимал ли наш соискатель систему оркестрации контейнеров Swarm или Kubernetes? Можно задать целый блок вопросов, но главное понять, делал человек работу своими руками с контейнерами или нет?

Спрашиваю про CI/CD deployment


Меня интересует огромный список вещей: как он настраивает автоматический deployment, как настраивает Continuous Integration? Как у него собираются приложения, использует ли он системы анализа кода (PVS-Studio, SonarQube). Как он пишет тесты или как интегрирует тесты, написанные разработчиками.

Делает ли он какое-то интеграционное тестирование этих сборок? Что дальше происходит с тем, что он собрал? Это как-то складывается в артфекаты или это упаковывается в docker-контейнеры, пушится в registry? Пусть расскажет, какие системы использовал для настройки CI/CD-процесса. Это могут быть и GitLab CI, и Circle CI, и какие-то облачные решения. А может быть, Jenkins, ну и про самописные скрипты на PowerShell не стоит забывать.

Скажи мне, как человек деплоит, и я все пойму. Он может деплоиться с помощью Helm в Kubernetes, Ansible, скриптами или чем-то еще самописным.

Про систему управления конфигурациями


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

Узнаю про умение писать код


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

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

Последние вопросы на собеседовании касаются хранилищ баз данных


SQL, NoSQL в чем различия, с чем работали? Чаще встречаю людей с опытом работы в PostgreSQL, реже MySQL. Задаю вопросы про индексы, может ли соискатель настроить реплику, может ли настроить логическую репликацию между табличками или просто данными. А что он будет мониторить в этом случае? А как ускорить базу?



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

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


Подытожу

  • сети
  • API-уровень
  • транспортный уровень TCP\UDP
  • протоколы DNS и HTTP
  • Linux
  • контейнерная и гипервизорная виртуализация
  • CI/CD
  • система управления конфигурациями
  • контейнеры
  • базы данных

Все это позволяет составить полную картину о человеке


Самое критичное в моем списке базовые знания. Не знаешь базу пора заканчивать собес.

Если человек не может мне ответить, что такое маска подсети, или не понимает, зачем нужны headers в HTTP в большинстве случаев такой соискатель получает наижирнейший минус в моей тетради. Разве тебе не любопытно было узнать, как работают все эти штуки, в которых ты тыкаешь курсором мышки?

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

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



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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru