Я обычный казахский парень и как обычный казахский парень, я работаю devopsом. Ну у нас в степи обычно как бывает, когда человеку даже овец пасти не доверяют, а таксовать машины нет, приходится работать в it. Долгое время я прятался от степных волков и казашек которым пора замуж, на проекте в налоговой, притворно изображая администратора. Со временем я научился делать это так умело, что даже матёрые админы замечать перестали. Этот театр одного актера продолжался долгие 15 лет. Но однажды принудительно возвращенный в офис с удаленки, с удивлением обнаружил что половина отдела приходят со своими рабочими проблемами и мне приходится их решать. Посидев в роли наставника пару дней, понял, пора валить. Начал искать работу, где я смогу притворяться за ту же сумму но не так много. Однажды на одном из собеседований, когда я рассказывал какие мохинаций с bash я применял, что бы ничего не делать, hr мне поставил диагноз "так ты этот... как его.., DevOps". Ого! подумал я "такими мы ещё не притворялись" и смело указал в резюме что DevOps. И с тех пор уже три года я успешно притворяюсь DevOps ом в разных фирмах. Это совсем просто прохожу одно собеседование за другим и когда появлялись вопросы на которые я не мог ответить, я просто иду читать ответы. А устроившись просто делал то что читал. И вот сегодня я вышел на новую работу в очередной раз я обманул devops senior-а рассказав как расцветёт его система с применением практик инфраструктурного кода. Он даже принял за чистую монету что ci на jenkins я использую, не потому что не знаю как это делается в gitlab, а потому что убежден что нельзя класть яйца репозитория и пайплайна в один сервис. Спустя какое то время, когда я выслушивал ответную его тираду "что микросервисы надо использовать только в том случае когда не можешь спрогнозировать нагрузку на систему". И тут меня осенило я имею дело с гениальным актером который научился притворяться на уровне senior DevOps. Придурка который открыл статью "какие вопросы надо задавать девопсу на собеседовании" я бы распознал сразу.
И вот первый рабочий день, начали мы как у них в обычаях со стендапа. Потому как он прошел закрались первые смутные сомнения. Senior в задачи погрузится не дал. На вопрос под какие ОС писать плейбуки? мне не внятно промычал и что то куда-то принялся писать. Какой вид бэкапа писать в плейбуке для mysql? сказали покамест не нужно писать его вообще. Из чего я понял что тех задание на испытательный месяц писали для меня на шару.
Senior поругал отвлеченого на посторонние разговоры в офисе девопса. Мол у нас дескать стендап, а ты отвлечен фу фу фу. Как бы показывая зубки альфача. А когда бета девопс начал что то тоже конкретизировать из серий "будет ли в плейбуке докер" последовал ответ он сам должен это спрашивать. А когда я повторил вопрос он не ответил. Ну думаю хрен с тобой senior помидор, самое место такому на rotten tomato's"
Где то два или три часа меня донимал бухгалтер требуя подписать все на свете.
Затем hr-ом я был запущен в корпоративный Битрикс где должен был ознакомиться с видео материалами. В сумбурные речи лекторов я вслушиваться не стал, в нашей профессии быстро учишься определять инфоциган торгующих рожей на фоне скрина какого-нибудь софта. Да мудрено ли с моим стажем в почти двадцать лет верить в сказки из серий "построение горизонтальных связей между работниками ускорит процесс согласования" ага щаз, вы мне ещё про "собор и базар" расскажите. Полтора часа ребята с видео, переливали из пустого в порожнюю, тыкая пальцем в схему о которой любая секретутка выразилась бы "ой бывала я в структурах и по больше". После увиденного смутные сомнения начали терзать с новой силой".
Окончательно точка поставлена была только во время прохождения материалов по логировнию, так они "протоколирование выполненных работ" у себя на иностранный манер обозвали. Снова и снова читая пяти страничный текст, я просто диву давался, как можно было простую мысль "записывайте за собой все что делаете" тонким слоем смысла натянуть на пять страниц с рисунками. Я всякое видел но такое, такое ощущение что у автора стояла задача зашифровать а не обьяснить. И когда я увидел тест в конце текста, все наконец-то встало на свой места.
Раз за разом проваливая тест на двух вопросах из шести, я разбирал ситуацию "Так значит ребята вы наняли инженера, час которого стоит как рандеву с путаной. И вместо того что бы дать доступ к aws, вы его талмудом от аутистов об тесты херачите? Сразу повеяло душком каворкинга родной нацкомпаний, в ней начальство так усердно делало вид что работает, что местами даже само в это верило. И вот эта вера и рождала в чреслах менеджмента, такие вот документы и тесты. Ну там то гос бюджет все понятно. А тут что происходит? А тут тоже самое, разница только в том весь этот театр для инвесторов. Через годик до инвестора дойдет что "царь не настоящий". А прибыль не женский оргазм, такое не сыграть. Если даже и получится, то на суде и бездарно как у Эмбер Херд. И пойду я с вами на hh собеседование клянчить. Подумал я и написал hr-у который как ни странно был самым настоящим "бро сори, но я сваливаю"
Потому что я притворяюсь почти 20 лет, уж я то в курсе как ложь огорчает, не умелая ложь бесит. А самообман это глупость вызывающая недоумение.

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

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

Доброго времени суток, пикабушники.

Прочитал пост @disabler и хотел бы рассказать обратную сторону поиска работы на должность админа Linux или DevOps.

Первый мой пост, не судите строго.

Для начала разберемся с теорией и почему я был не прав.

Задачи DevOps:

- понимание своей роли в процессах разработки по гибкой методологии

- обеспечивать CI/CD для быстрого тайм-ту-маркет сервиса или фичи

- использовать суперкрутые декларируемые средства автоматизации (SaltStack, Ansible)

- владеет Git и крутыми аналогами

- использует Bash, python для автоматизации

- собирать пакеты deb/rpm

Linux админ:

- админит сервисы (DNS, DHCP, файловую систему)

- админит веб-сервера

- админит виртуалки (c linux конечно 80%, ну у нас есть некоторые сервисы на Windows их тоже надо админить, частенько это слышу, но это скорее, как хвостик, чем приоритет, оно и понятно)

- сеть виртуалок (iptables, firewalld, автоматизируй, как скажут или как хочешь)

- админит гипервизоры

- диагностирует сбои на виртуалках и гипервизорах

- организует и следит за бекапами

- Kubernetes, PostgreSQL, HAProxy

- использует Bash, python для автоматизации

- все, что угодно в зависимости от требований компании

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

Если раньше, например, в банках и крутых организациях было модно на каждый продукт, на каждый компонент, типа приложения, Windows и Linux, гипервизоры, найти своего инфраструктурного или прикладного админа, то и гиганты передовики ищут такого админа, который каким-то образом освоил ansible или saltstack, есть понимание как работает CХД, как объявлять LUNы и т.д. и как это сделать устойчивым, работал с железными серверами, SAS или FC коммутаторами, умеет работать с гипервизорами, но еще и успел поработать с модными технологиями типа ElasticSearch.

Как обстоят дела с банками сейчас я не знаю.

Погуглите hh.ru, увидите сколько всего должен уметь Linux-админ. А потом загуглите на hh.ru что должен делать DevOps. И попробуйте понять кто им, блин, нужен.

Очень часто на вакансию DevOps откликаются с предложением Linux-админа. Не вопрос, все обсуждается.

Вспоминается картинка

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

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

Давайте разберем вопросы, которые спрашивают на собеседовании

Поговорим о linux-админе:

"Работали ли вы с OpenStack или OpenNebula"

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

"расскажи, что есть в top"

Я, кстати, завалился на load average и %Cpu(s), чет их много, поставил галочку изучить.

"Есть пользователь, который выгружает доки по FTP в Интернет, у себя дома у него работает, на работе нет, что это может быть"

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

"Если у нас очень много всего и логировать близко к нереальному, забьем место логами и сломаем что-нибудь еще"

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

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

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

Тут смысл в том, на сколько критичны данные, если критичны - потренируйся перенаправлять данные через пайпы "|" в Bash.

Если не критичны - очистить открытый файл через файл-дескриптор.

Лучше отработать это заранее, никто не хочет, чтобы ты учился на боевых серверах.

Изучить: lsof, strace, Inode, файл дескрипторы.

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

Запомнить: решил проблему быстро, но она может повториться, сделай все, чтобы не повторялась, желательно по Best-practice.

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

"Физический сервер встает клином, по сети и другим вещам не доступен, что будешь делать"

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

Если сервер встал, скорее всего iKVM тоже повиснет, хоть так, хоть эдак.

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

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

Правильный ответ опять не спросил.

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

Поговорим о DevOps

Недели две назад я ходил на собеседование как раз на DevOps, это было самое жесткое собеседование.

Для начала, мои советы:

-точно знай "что" делает DevOps

-почему бытует мнение, что в России нет DevOps

-готовься и гугли технологии

-ИДИ

-ВСЕГДА

-С ЧИСТОЙ

-ГОЛОВОЙ

-ОТ ДРУГИХ

-ПРОБЛЕМ И ЗАДАЧ.

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

"поговорим об ansible"

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

Изучить: стуктура ansible, бест-практики.

"поговорим о python, у нас есть список элементов из числел, напиши код, который выдает нам простые числа"

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

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

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

"поговорим о python"

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

Изучить: базовые алгоритмы компьютер саенс.

"поговорим о JOIN и SQL"

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

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

Сразу скажу, то, что ты защитит лет 12 назад диплом Delphi + MS SQL - никого не впечатляет. Бизнесу это не интересно, имхо, сложилось впечатление, что это равносильно вспомнить Turbo Pascal, который вы проходили в школе.

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

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

"зачем вообще DevOps"

Рассказал про гибкие методики, про классическую waterfall model и что она немного не актуальна, а на практике время показало, что требования бизнеса очень переменчивы, соответственно все эти DevOps методики и инструменты позволяют быстро предоставить то, что нужно бизнесу или пользователям.

А мне сказали, что DevOps способствует time-to-market.

Подзадумался. Ответ зачем DevOps нужен я так и не получил.

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

Немного организационных моментов:

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

2. Работодатели редко отвечают за 1-2 рабочих дня, тянется это все неделями, сразу после собеседования редко кто может сказать: "Да, знаешь, чувак, чет рановато тебе к нам". Надо посовещаться. Этика?

3. Очень большое количество технологий пересекается в вакансиях на DevOps и на Linux-админа.

В моем понимании админ больше работает с DevOPS, сетевиками и железом, DevOps - с разработчиками, QA, тестировщиками и т.д. Все зависит от того, как выстроены процессы.

Так что Вам нужно, дорогие работодатели?

Дискас.

Открытая инфраструктура.

В терминологии DevOps есть "инфраструктура" - набор виртуальных машин, баз данных, сетевых настроек, VPN, присоединённых дисков и т.п.
Термин "открытая инфраструктура" никогда не слышал. Есть "открытый код" (open source).

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

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

Infrastructure as a code - подход управления IT инфраструктурой, где DevOps, по сути, описывает кодом (похожим или являющимся языком программирования), как эта структура должна выглядеть, правила её создания и взаимодействия компонентов.
Это позволяет, например, с нуля полностью пересоздать инфраструктуру, отслеживать ресурсы. Если у вас 200 одинаковых виртуальных машин, вы  один раз описали её параметры, свойства и т.п. и просто указали "200" в параметре "количество".
Популярный инструмент описания инфраструктуры - Terraform

****набор букв подряд****

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

99.9999...9% - параметр надёжности.
Шутки-шутками, но довольно важный параметр, например:
Источник

Кластер - почти всегда подразумевают Kubernetes кластер (https://ru.wikipedia.org/wiki/Kubernetes) - пространство для выполнения Docker (в 99% случаев) контейнеров, которые упоминаются ниже. В кластере можно настраивать какие контейнеры запущены, делать масштабирование, обновление, перезагрузку, направлять на них (контейнеры) траффик извне.

"кластер под каждый дом" - здесь немного высмеивается подход облачных провайдеров, где вы можете выбирать страну, регион, например запад США. Делается это для того, что бы сделать быстрее доступ к сервису пользователей. Например, если взять Netflix, то им разумно видео траффик для европейцев слать с Нидерландов или Гамбурга. Для восточной США из Северной Виргинии.
https://aws.amazon.com/ru/about-aws/global-infrastructure/regions_az/?nc1=h_ls

"меняем несколько переменных в YAML / JSON".
Современные форматы файлов для описания данных определённой структуры. JSON изначально создавался для Javascript (Javascript Object Notation), YAML позже, он лаконичней и выглядит чище (из-за использования табуляций вместо скобок).
Когда можно перенастроить систему, изменив в одном/паре мест параметр, то это признак хорошо организованного продукта (не только DevOps архитектуры).

Infrastructure as a code.

Scaling гейджи. Не знаком с аббревиатурой и вообще непонятно как её записать ? GayG ? GG ?
Scaling - горизонтальное масштабирование сервисов, что бы справляться с увеличенной нагрузкой. В т.ч. некоторые облачные провайдеры предлагают auto-scaling - автоматическое масштабирование в зависимости от нагрузки.
Как пример - у вас интернет магазин феерверков, у вас 1000 посетителей в день, а 29 декабря начинает приходить 100 000. Вам нужно, что бы сайт справился с нагрузкой, грамотный скейлинг помагает решить вопрос.

pilot master ? - хер знает.

Work/life balance - популярная в IT тема. Кто-то фигачит до поздних вечеров, кто-то срывается в 18:00 к семье. На эту тему много холиваров и обсуждений.

CI/CD

https://ru.wikipedia.org/wiki/CI/CD

CI - автоматическая сборка проекта, выполнение тестов и т.п. после того, как разраб залил изменения в главную (или другую) ветку репозитория с изменениями.

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

fatality? pipeline - первое слово не встречалось в этом контексте. pipeline - подразумевается конвеер операций, в плане DevOps имеется ввиду обычно CI/CD упомянутый выше. Как и на реальном конвеере, в нашем случае выполняется серия действий, только над продуктом, изменениями. Обычно здесь включены действия компиляции, создание Docker образа, запуск тестов, конфигурация, добавление чувствительных параметров (ключи доступа, пароли).

Kuber - имеется ввиду Kubernetes cluster, описан выше.
Пушишь - заливаешь изменения в код продукта на сервер/репозиторий, некое центральное место, где лежит программный код продукта.

Docker Container
https://ru.wikipedia.org/wiki/Docker
По сути, что-то типа виртуальной машины (ниже), только обрезанная до минимума, не всегда изолированная от внешней операционной системе, в которой живёт.
Основная цель которого (контейнера) - создать пространство библиотек, файлов для выполнения компоненты продукта, где всё настроено именно для этого компонента. Можно сравнить docker container с комнатой, где есть все необходимые инструменты. Например, кабинет стоматологии, рем зона СТО с подъёмником, массажный кабинет и т.п.

Виртуальная машина

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

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

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

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

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

Дежурство.

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