В Альфа-Банке был один из самых интересных собесов на позицию DevOps-инженера (всего технических было пару десятков)Как сказал собеседующий инженер: мне "повезло", ведь они тестят новый формат техсобесов - блиц Интенсивный собес с кучей адекватных технических вопросов с максимально быстрыми ответами
Жертвы ЕГЭ не иначе. Даже не знаю почему собеседующий так радуется. Опыт показывает, когда человек правильно отвечает на вопросы, это совершенно не значит, что он понимает, о том что говорит (привет ИИ). Тем более, что сейчас многие "наблатыкались" правильно отвечать, но не более.
Минус один: нельзя пообсуждать какие то вопросы, это мешает в полной мере раскрыться самому и раскрыть собеседующих как инженеров
Здесь ещё второй минус - нельзя задавать вопросы собеседующему. Это могут быть уточняющие, могут быть встречные, могут быть вопросы для обдумывания. У меня ещё советское техническое образование и нас учили, даже требовали, задавать вопросы, задаваться вопросами.
Оффер был на руках уже через неделю, с последующим моим (по глупости) отказом))
Не стоит совершенно об этом жалеть. Высокая ЗП (кто сказал, что высокая?) не всегда оправдывает условия и устои.
Что касается автора статьи, по памяти работы в Т1, приходится ещё их доучивать или переучивать. Там такие шедевры иногда получались, на знаменитом сайте для этих вещей нужна отдельная рубрика.
Ну самое главное для понимания: Для чего нужен DevOps-инженер? Перво наперво это сборка и доставка кода (то самое CI / CD). Всё остальное вторично, третично, либо вообще не имеет никакого отношения DevOps. Кстати, как раз на эту тему есть довольно хорошая статья про DevOpsи его основные показатели.
Спасибо за интересную и познавательную статью. Можете прокомментировать тему прямого преобразования ионизирующего излучения в электрический ток? Есть ли подвижки и действующие решения?
В наших палестинах аббревиатура ИБ в сути своей часто расшифровывается как имитационная безопасность. Обычно там много бюрократии, присутствует своя артистократия и труднообъяснимые внутренние процессы выработки и принятия решений.
Написание жалобы во многие надзорные органы часто выглядит труднопроходимым квестом. Видимо изначально так было задумано. Как и последующее перенаправление в долгий ящик всех этих жалких обращений от людишек.
Гальваническая развязка нужна для других целей и они не связаны с ИБ. Потому что трансформатор обратимое устройство и ему by design всё равно в какую сторону трансформировать электрическую энергию: первичная и вторичная обмотки так называются только для удобства восприятия. Поэтому, чтобы избежать прелести с передачей данных по электрической сети надо применять схему двойного преобразования: переменка -> постоянка -> переменка
Есть в команде отличный разработчик Вася. Он делает больше задач за спринт, чем вся команда вместе взятая. Инициативный, амбициозный, систему знает как свои пять пальцев — не он строился вокруг сервисов, а сервисы вокруг него. И вот приходит момент повышения — технический директор говорит: «Теперь, Вася, ты менеджер. Руководитель команды». Вася воодушевлен и идёт управлять.
Небольшая притча перед комментарием: "Больше всех в колхозе работала лошадь, но председателем колхоза она не стала".
С точни зрения целесообразности бизнесу не всегда выгодно терять рабочую единицу, которая выполняет много работы и обладает высокими комптенциями. Потому что вместо условного Васи нужно найти подходящую замену, желательно равнозначную. Кроме этого на новой должности Вася некоторое время не будет показывать ожидаемой эффективности в качестве руководителя. Не факт что сможет справиться. Поэтому часто можно наблюдать найм руководителя вместо продвижения имеющихся сотрудников.
Отдельно обстоят дела, когда условный Вася сотрудник на удалёнке. Я понимаю, что в современный век мгновенных коммуникаций, это не большая проблема. Только многолетнее наблюдение (ещё с доковидных времён) показывает, что щансы стать руководителем команды или подразделения (управленцем) у удалёнщика крайне невелеки. Причём, обратно пропорциональны его удалению от офиса.
Какие золотые сигналы собираетесь мониторить и как на них реагировать? И почему эти сигналы должны быть золотыми?
Предполагаю, но не утверждаю (ибо могут быть иные побудительные мотивы), что это делается для улучшения процессов в компании. Но (далее цитата) у любого улучшения процесса должны быть метрики, и помимо улучшения расхода энергии (достаточного условия) нужно ещё иметь отрицательный признак ухудшения (необходимое условие). Улучшение должно показать улучшение положительной метрики и неухудшение отрицательной. Потому что без отрицательной метрики я вам могу ОЧЕНЬ много электричества сэкономить. Не грейте сталь вообще - положительная метрика (экономия) зашкаливает. А что сталь не плавится - так условия-то "плавить хорошо" нет
Интересное замечание. Просто обычно keycloak располагают внутри закрытого сетевого контура и это совсем не демилитаризованная зона, а приватная сеть доступная при подключении через тоннель. Кроме этого сам keycloak поддерживает репликацию из коробки.
Когда у вас около десяти серверов и более менее устоявшийся коллектив без постоянной текучки кадров и непонятных хотелок, процесс смены ключей (паролей) SSH может быть довольно простым и не таким частым (ansible role - самый распространённый вариант). А когда у вас с полсотни серверов и постоянно надо давать и забирать права доступа, высока вероятность запутаться и допустить ошибку.
Также keycloak поддерживает MFA (SMS, Email, TOTP, WebAuthn) поэтому можно настроить довольно надёжную схему. Но если выставить бездумно сервер IAM/IdP, собранный на коленке и запущенный через docker-compose, тогда остаётся уповать только на чудо.
буквально с первых дней погрузилась в перезапуск бренда работодателя
Можете привести примеры, что именно не так по вашему было с брендом работодателя? До чего докатились?
25+ лет на российском ИТ-рынке, многие сотрудники работают чуть ли не с основания, есть крутые проекты с государством и корпоративным сектором
Ни в коем случае не ставлю под сомнение квалификацию технического персонала, но 25 лет на одном месте... С другой стороны госуха (проекты с государством) и поди банки (корпоративный сектор) ну такой себе показатель особенно в наших реалиях.
Мы далеки от романтизированного айтишного вайба с послеобеденным сном и «плюшками». И нам нужны именно такие люди, готовые с нами разделить наши ценности и цели – достичь большего
1 Что не так с романтизированным айтишным вайбом с послеобеденным сном и «плюшками» по вашему? Что вы готовы предложить кроме запоминающегося образа в глазах сотрудников и соискателей? 2 Какие ценности в вашей компании? 3 Именно большего чего собиратесь добиться?
Ты можешь предложить баснословную зарплату кандидату, но при аналогичных условиях, если бренд не на слуху, он выберет другую компанию.
Вы крайне далеки от реального положения на рынке труда. Уже прошло то поколение, которое велось на: "работать в нашей компании большая честь"
Ситуация начала меняться в январе-марте этого года – после годовых премий часть специалистов традиционно вышла на рынок, но не нашла большого количества достойных предложений
Далеко не во многих компаниях ИТ есть премии и годовые тоже. Большинство уходят, потому что часто это единственный способ увеличить свой доход. Есть те которые достигли своего потолка и ищут новое место роста. Но не из-за годовых премий.
Меняется и структура спроса – если раньше сметали всех, включая джунов, то сегодня предпочтение отдается
Требуются высококвалифицированные, опытные, отвественные и недорогие специалисты (ц)
Не забываем мы и о внутренней аудитории. Нам кажется важным донести до каждого члена нашей команды информацию о том, какой мы работодатель, какая у нас миссия и ценности, какие качества мы ценим в людях. И это не просто красивые слова и новый мерч, нам важно, чтобы каждый сотрудник смог почувствовать изменения.
1 Рассказывать своим сотрудникам какие вы хорошие, ну такое себе 2 Ни мерчем, ни красивыми словами профессионала не удержишь
Озвучил как-то в канале разработчиков, озвучил как-то в канале с бизнесменами, что сейчас не рынок кандидата, как считают первые, и не рынок нанимателей, как думают вторые. И одни и другие упорно убеждали в обратном, а именно, что сейчас не рынок рекрутеров. Но именно рекрутеры, ресёрчеры решают кому быть, а кому не быть. Увы, сейчас очередное подтвеждение.
Вызнаете, полностью с вами согласен не только по этой статье, но и по прошлым. Могу заверить, что описанное вами поверено и проверено на собственном опыте и опыте знакомых. А практика - критерий истины.
режим творчества включается только в состоянии «пассивного режима», когда мозг находится в расслабленном состоянии, а человек словно бы бездельничает
У нас такое не все большие начальники себе позволяют. А работникам такое вообще под запретом) Поэтому наше творчество обычно вымученное или выстраданное. Что можно заметить по многим отечественным продуктам. Ну а эффективность измеряется усталостью.
Тем не менее, даже для кирпича с двигателем боевой радиус важен. Если можно поставить один двигатель вместо двух -- ставят один.
У боевого кирпича кроме боевого радиуса многожество других не менее важных параметров. В большинстве реализаций таких боевых кирпичей этих двигателей стоит две штуки.
А два двигателя ещё и обслуживать нужно в два раза больше, чем один
Но при этом на большинстве транспортников Пентагона стоит не менее 4-х двигателей (очень дорогих изделий) и органы управления многократно дублируются. В пассажирских мы тоже можем наблюдать аналогичную картину, где двигателей не менее 2-хштук. И это никого не смущает, как и то что после посадки и перед взлётом борты проходят проверку и подготовку. Цена вопроса настолько велика, что никто не будет думать о таких вещах как КПД, там больше рулит наработка на отказ.
Если оружиие одноразовое, то при условии достижения нужных ТТХ можно городить любую дичь.
С оружием такое не работает. Потому что оно убивает или колечит. Это работает от светошумовой гранаты до атомной бомбы.
Если же штука многоразовая со сроком службы в десятки лет, то считают TCO
Везде своя специфика, но что касается вооружения обычно на первом месте стоит эффективность (иначе какой смысл в неэффективном оружии?) и надёжность.
мы работаем с облачным хранилищем секретов, а это более тонкая сущность нежели виртуальная машина или meneged service
В чём именно тонкость сущности облачного хранилища секретов? Там вроде нет ничего такого по сравнению с аппаратным HSM.
Представьте, у вас несколько сотен записей, которые периодически надо менять, и, чаще всего, читать в самых разных сценариях, для которых у вас уже написаны плейбуки и роли.
Давайте всё же будем честны. Периодическое обновление записей никак не кореллирует с чтением. Операция чтения идемподентна и нас никак не должна волновать нас. Поэтому это нельзя никак считать в качестве аргумента.
И вот вы пишете кучу однотипных манифестов с ресурсами по документации ..... складываете в отдельный репозиторий, а когда вам надо изменить секрет, пишете ещё манифест
Могу только заметить, что измнение переменной или добавление новой не должно приводить к написаню нового манифеста. У вас где-то рекурсия, с которой надо разобраться. Потому что это совсем не декларативный стиль описания. Должно быть: вы изменили переменную в коде, она автоматически изменилась в инфраструктуре (у вас для этого должны быть pipeline)
И да, читать из секрета через data удобно только внутри терраформа, а реализовать чтение "на лету" при выполнении плейбука ansible - это отдельный квест, и параметр "скорость выполнения сценария" при реализации возрастёт в разы
Но вы сами выбрали инструменты и неподходящую парадигму. Параметр "скорость выполнения сценария" больше зависит от правильности выбранного алгоритма, оценки его сложности и правильной реализиции. Поэтому сложность реализации процедуры "чтение переменных из терраформа" при выполнении плейбука ansible целиком и полностью на плечах задумавшего такое.
Далее, вы спрашиваете, почему передавать секреты через репозиторий, шифруя их c помощью ansible-vault или sops+age, небезопасно. Отвечаю кратко: человеческий фактор.
Тогда под этот критерий попадает практически любая реализация криптографии. Это не ответ на вопрос небезопасности касаемо криптографических инструментов таких как ansible-vault или sops+age. Таким образом ваша реализация аналогично никак не застрахована от человеческого фактора. Тем более для реализации безопасного взаимодействия между командой разработки и командой девопс вам необходим защищённый канал, когда разработчику надо передать переменную команде девопс, которую надо добавить в секреты, либо команде девопс надо передать переменную команде разработки, чтобы выполнить тесты.
Добавлю ещё ремарку про ваше высказывание о том, что код терраформа сам себя документирует
Не писал такого, что код (любое приложение) сам себя документирует. Документация к коду и сам код немного разные вещи. Иногда совсем.
Можно сколько угодно твердить "мы должны использовать Terraform только для работы с инфраструктурой!", но, если молоток не не приспособлен под задачу вкручивания шурупов, не лучше ли взять шуруповёрт?
Хороший вопрос. Часто его приходится задавать людям, которые решили засунуть всё в кубернетес, тем самым (по их мнению) решив все проблемы. Приходилось встречаться с различными применениями Terraform от управления доменными учётными записями и развёртыванием приложений в k8s, до управления дашбордами мониторинга. Но вы сами сказали что молоток (ansible) изначально не предназначен для управления облачной инфраструктурой (даже в документации ЯОблака нет ни одного примера работы с инфраструктурой при помощи ansible), поэтому правильнее воспользоваться шуруповёртом (в документации ЯОблака практически каждый пример работы с инфраструктурой описывается при помощиTerraform). Тем более ЯОблако постоянно обновляет драйвера TF для своего облака и приводит для него примеры в своей документации.
Спасибо вам за хорошую и самое главное полезную статью. Многие вещи стали ясны и понятны
Жертвы ЕГЭ не иначе. Даже не знаю почему собеседующий так радуется. Опыт показывает, когда человек правильно отвечает на вопросы, это совершенно не значит, что он понимает, о том что говорит (привет ИИ). Тем более, что сейчас многие "наблатыкались" правильно отвечать, но не более.
Здесь ещё второй минус - нельзя задавать вопросы собеседующему. Это могут быть уточняющие, могут быть встречные, могут быть вопросы для обдумывания. У меня ещё советское техническое образование и нас учили, даже требовали, задавать вопросы, задаваться вопросами.
Не стоит совершенно об этом жалеть. Высокая ЗП (кто сказал, что высокая?) не всегда оправдывает условия и устои.
Что касается автора статьи, по памяти работы в Т1, приходится ещё их доучивать или переучивать. Там такие шедевры иногда получались, на знаменитом сайте для этих вещей нужна отдельная рубрика.
Ну самое главное для понимания: Для чего нужен DevOps-инженер? Перво наперво это сборка и доставка кода (то самое CI / CD). Всё остальное вторично, третично, либо вообще не имеет никакого отношения DevOps. Кстати, как раз на эту тему есть довольно хорошая статья про DevOps и его основные показатели.
Спасибо за интересную и познавательную статью. Можете прокомментировать тему прямого преобразования ионизирующего излучения в электрический ток? Есть ли подвижки и действующие решения?
В наших палестинах аббревиатура ИБ в сути своей часто расшифровывается как имитационная безопасность. Обычно там много бюрократии, присутствует своя артистократия и труднообъяснимые внутренние процессы выработки и принятия решений.
Написание жалобы во многие надзорные органы часто выглядит труднопроходимым квестом. Видимо изначально так было задумано. Как и последующее перенаправление в долгий ящик всех этих жалких обращений от людишек.
Гальваническая развязка нужна для других целей и они не связаны с ИБ. Потому что трансформатор обратимое устройство и ему by design всё равно в какую сторону трансформировать электрическую энергию: первичная и вторичная обмотки так называются только для удобства восприятия.
Поэтому, чтобы избежать прелести с передачей данных по электрической сети надо применять схему двойного преобразования:
переменка -> постоянка -> переменка
По сути напоминает импульсный источник питания.
Небольшая притча перед комментарием: "Больше всех в колхозе работала лошадь, но председателем колхоза она не стала".
С точни зрения целесообразности бизнесу не всегда выгодно терять рабочую единицу, которая выполняет много работы и обладает высокими комптенциями. Потому что вместо условного Васи нужно найти подходящую замену, желательно равнозначную. Кроме этого на новой должности Вася некоторое время не будет показывать ожидаемой эффективности в качестве руководителя. Не факт что сможет справиться. Поэтому часто можно наблюдать найм руководителя вместо продвижения имеющихся сотрудников.
Отдельно обстоят дела, когда условный Вася сотрудник на удалёнке. Я понимаю, что в современный век мгновенных коммуникаций, это не большая проблема. Только многолетнее наблюдение (ещё с доковидных времён) показывает, что щансы стать руководителем команды или подразделения (управленцем) у удалёнщика крайне невелеки. Причём, обратно пропорциональны его удалению от офиса.
Какие золотые сигналы собираетесь мониторить и как на них реагировать? И почему эти сигналы должны быть золотыми?
Предполагаю, но не утверждаю (ибо могут быть иные побудительные мотивы), что это делается для улучшения процессов в компании. Но (далее цитата)
у любого улучшения процесса должны быть метрики, и помимо улучшения расхода энергии (достаточного условия) нужно ещё иметь отрицательный признак ухудшения (необходимое условие). Улучшение должно показать улучшение положительной метрики и неухудшение отрицательной. Потому что без отрицательной метрики я вам могу ОЧЕНЬ много электричества сэкономить. Не грейте сталь вообще - положительная метрика (экономия) зашкаливает. А что сталь не плавится - так условия-то "плавить хорошо" нет
Иначе будет и в основном бывает как в песне:
Здесь мерилом работы считают усталость
Интересное замечание. Просто обычно keycloak располагают внутри закрытого сетевого контура и это совсем не демилитаризованная зона, а приватная сеть доступная при подключении через тоннель. Кроме этого сам keycloak поддерживает репликацию из коробки.
Когда у вас около десяти серверов и более менее устоявшийся коллектив без постоянной текучки кадров и непонятных хотелок, процесс смены ключей (паролей) SSH может быть довольно простым и не таким частым (ansible role - самый распространённый вариант). А когда у вас с полсотни серверов и постоянно надо давать и забирать права доступа, высока вероятность запутаться и допустить ошибку.
Также keycloak поддерживает MFA (SMS, Email, TOTP, WebAuthn) поэтому можно настроить довольно надёжную схему. Но если выставить бездумно сервер IAM/IdP, собранный на коленке и запущенный через docker-compose, тогда остаётся уповать только на чудо.
Можно ещё каждый дейлик начинать с этого
Можете привести примеры, что именно не так по вашему было с брендом работодателя? До чего докатились?
Ни в коем случае не ставлю под сомнение квалификацию технического персонала, но 25 лет на одном месте... С другой стороны госуха (проекты с государством) и поди банки (корпоративный сектор) ну такой себе показатель особенно в наших реалиях.
1 Что не так с романтизированным айтишным вайбом с послеобеденным сном и «плюшками» по вашему? Что вы готовы предложить кроме запоминающегося образа в глазах сотрудников и соискателей?
2 Какие ценности в вашей компании?
3 Именно большего чего собиратесь добиться?
Вы крайне далеки от реального положения на рынке труда. Уже прошло то поколение, которое велось на: "работать в нашей компании большая честь"
Далеко не во многих компаниях ИТ есть премии и годовые тоже. Большинство уходят, потому что часто это единственный способ увеличить свой доход. Есть те которые достигли своего потолка и ищут новое место роста. Но не из-за годовых премий.
Требуются высококвалифицированные, опытные, отвественные и недорогие специалисты (ц)
1 Рассказывать своим сотрудникам какие вы хорошие, ну такое себе
2 Ни мерчем, ни красивыми словами профессионала не удержишь
Какие замечательные и главное полезные советы (ирония).
Озвучил как-то в канале разработчиков, озвучил как-то в канале с бизнесменами, что сейчас не рынок кандидата, как считают первые, и не рынок нанимателей, как думают вторые. И одни и другие упорно убеждали в обратном, а именно, что сейчас не рынок рекрутеров. Но именно рекрутеры, ресёрчеры решают кому быть, а кому не быть. Увы, сейчас очередное подтвеждение.
Вызнаете, полностью с вами согласен не только по этой статье, но и по прошлым. Могу заверить, что описанное вами поверено и проверено на собственном опыте и опыте знакомых. А практика - критерий истины.
У нас такое не все большие начальники себе позволяют. А работникам такое вообще под запретом) Поэтому наше творчество обычно вымученное или выстраданное. Что можно заметить по многим отечественным продуктам.
Ну а эффективность измеряется усталостью.
Было хотел ответить прозаически:
Сон мне, белые кресты
И лечу куда-то...
Но потом вспомним хорошую картинку
Какой ценой? Особенными требованиями к чистоте, длинне и ровности ВПП.
Ну у МиГ-9 и МиГ-15 тоже был один двигатель. Ровно по той же причине как у МиГ-1 и МиГ-3)) Только потом почему-то отказались от этой схемы
Вроде как давно такие устройства производит концерн Калашников
У боевого кирпича кроме боевого радиуса многожество других не менее важных параметров. В большинстве реализаций таких боевых кирпичей этих двигателей стоит две штуки.
Но при этом на большинстве транспортников Пентагона стоит не менее 4-х двигателей (очень дорогих изделий) и органы управления многократно дублируются. В пассажирских мы тоже можем наблюдать аналогичную картину, где двигателей не менее 2-хштук. И это никого не смущает, как и то что после посадки и перед взлётом борты проходят проверку и подготовку. Цена вопроса настолько велика, что никто не будет думать о таких вещах как КПД, там больше рулит наработка на отказ.
С оружием такое не работает. Потому что оно убивает или колечит. Это работает от светошумовой гранаты до атомной бомбы.
Везде своя специфика, но что касается вооружения обычно на первом месте стоит эффективность (иначе какой смысл в неэффективном оружии?) и надёжность.
В чём именно тонкость сущности облачного хранилища секретов? Там вроде нет ничего такого по сравнению с аппаратным HSM.
Давайте всё же будем честны. Периодическое обновление записей никак не кореллирует с чтением. Операция чтения идемподентна и нас никак не должна волновать нас. Поэтому это нельзя никак считать в качестве аргумента.
Могу только заметить, что измнение переменной или добавление новой не должно приводить к написаню нового манифеста. У вас где-то рекурсия, с которой надо разобраться. Потому что это совсем не декларативный стиль описания. Должно быть: вы изменили переменную в коде, она автоматически изменилась в инфраструктуре (у вас для этого должны быть pipeline)
Но вы сами выбрали инструменты и неподходящую парадигму. Параметр "скорость выполнения сценария" больше зависит от правильности выбранного алгоритма, оценки его сложности и правильной реализиции. Поэтому сложность реализации процедуры "чтение переменных из терраформа" при выполнении плейбука ansible целиком и полностью на плечах задумавшего такое.
Тогда под этот критерий попадает практически любая реализация криптографии. Это не ответ на вопрос небезопасности касаемо криптографических инструментов таких как ansible-vault или sops+age. Таким образом ваша реализация аналогично никак не застрахована от человеческого фактора. Тем более для реализации безопасного взаимодействия между командой разработки и командой девопс вам необходим защищённый канал, когда разработчику надо передать переменную команде девопс, которую надо добавить в секреты, либо команде девопс надо передать переменную команде разработки, чтобы выполнить тесты.
Не писал такого, что код (любое приложение) сам себя документирует. Документация к коду и сам код немного разные вещи. Иногда совсем.
Хороший вопрос. Часто его приходится задавать людям, которые решили засунуть всё в кубернетес, тем самым (по их мнению) решив все проблемы. Приходилось встречаться с различными применениями Terraform от управления доменными учётными записями и развёртыванием приложений в k8s, до управления дашбордами мониторинга. Но вы сами сказали что молоток (ansible) изначально не предназначен для управления облачной инфраструктурой (даже в документации ЯОблака нет ни одного примера работы с инфраструктурой при помощи ansible), поэтому правильнее воспользоваться шуруповёртом (в документации ЯОблака практически каждый пример работы с инфраструктурой описывается при помощи Terraform). Тем более ЯОблако постоянно обновляет драйвера TF для своего облака и приводит для него примеры в своей документации.