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



    Я начал заниматься сетями еще в школе, а работаю за деньги больше 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 и сети.

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


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

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

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

    Comments 123

      –5
      Как то слабовато))) это джун?

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

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

        плюсанул бы, но не довопс :)
        а так да… кстати, там еще про нейросети и машинное обучение забыли. какой девопс без ML?

          –5
          Соглашусь. Когда последний раз меня попросили помочь с наймом в мелкоконторку(конторка в Монреале), была в ужасе, что 3 из 6 соискателей не смогли назвать отличие list от tuple в питоне, при том, что заявлен он был у всех, а когда спросила про то, как тестировать лямбду в контексте AWS(подряд несколько вопросов было про AWS) — я верю, что DevOps/SRE суть разработчик infrastructure-as-code, а каждый разработчик должен уметь писать юнит-тесты к своему коду — ни один из них не вспомнил что это вообще такое. Только один подумал, что речь о лямбда функциях в питоне, и стал говорить что-то про них. Я даже почти хотела его взять, но увы, он забил писать тестовое задание.
            +2

            Никогда не понимал зачем человек который умеет писать на 2-3 языках пойдет в девопс.


            Если можно получать в 2 раза больше работая обычным разрабом. И там тебе не будут рвать мозг.

              +1
              основное — это интересно, архитектура, приходится решать очень сложные задачи, ну и с зп вы загнули, по вашему обычный разраб легко получает 500к?
                0

                500к у девопс. Смешно да. 100-250 вилка обычная. 500к получают далеко не рядовые спецы. Но не рядовые разрабы получают ещё больше)

                  0
                  У нас джун DevOps/SRE получает тысяч 70 канадских долларов в год, сеньёр тысяч 90-150. Люди более крутых грейдов (могут называться по-разному в разных компаниях, например, принципалы) получают ещё больше — это о крутых спецах. Лично я к их числу не отношусь. Я миддл, которая работает на сеньёрской позиции :)
                  Ещё ради спортивного интереса я проходила цикл интервью и получила оффер миддл бэкэнд разработчика (писать REST API на Flask/ORM/MySQL/Mongo/swagger), и там было меньше, чем на сеньёрской DevOps позиции.
                    0

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

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

                      Зависит от стека. Более того, я считаю девопсов разработчиками, но инфраструктуры. Есть стеки, где разработчики получают больше, есть где меньше. Внутри девопсов тоже не одинаково, те же Golang/Kubernetes девопсы явно дороже других.
                        0

                        при этом "у вас" — это не то же самое, что "у нас" (применительно, я думаю, к любым странам/территориям).

                  0
                  Мозг могут рвать «везде», это скорее от руководителя и компании зависит. Умение писать на разных языках — это не дар, а нарабатываемый навык. Если человеку нравится учить языки и применять их в DevOps — почему бы и нет. Другое дело, что как правило, от программистов требуется более глубокое знание языка, библиотек и frameworks.
                    +1

                    В некоторых странах DevOps больше или сопоставимо получает, чем разработчики

                      0
                      Так нормальный девопс и есть разработчик, только инфраструктурной части приложения, типа фронтэнд, бэкэнд, ML-инженер, DBA, и вот девопс. Что не так?
                      И там тебе не будут рвать мозг.

                      Зачем люди, не хотящие учиться, вообще нужны? Девопс это не эферемизм для админов, которые считают себя немножко лучше других, научившись писать баш скрипты, и прочитавшие пару книжек по terraform, запустившие кликанием мышки разок в жизни Google Kubernetes Engine, в сравнении со своими коллегами, всё ещё мышкатыкающими в MS AD,
                        0

                        Девопс это не эферемизм для админов. Ага это в целом даже не специальность, а методология для работы в команде).


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


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


                        Самое главное. Если кто то нанимает devops это не значит что к компании все работает по devops. Писать скрипты на yaml или автотесты и уметь пользоваться гитом. Это немного не то пальто и это умеют и разные разрабы и разные админы, и давно умели. Без всяких модных слов.

                          0

                          К слову а то про что говорите называется SRE или Software Engineer ну или DBA или ML-инженер. И вот это уже конкретные прикладные специальности с конкретными задачами. И вот тут уже без знания программирования никуда. Но опять же так как это прикладные задачи, а не сферическая методология в вакууме. То к ним будут конкретные требования, по тому стеку что используется в этой компании. А не все подряд. И если там пишут на go например. то им и нужен будет человек который пишет на go.

                            0
                            К слову а то про что говорите называется SRE или Software Engineer ну или DBA или ML-инженер

                            Разница между DevOps и SRE в том, что первый с уклоном в в CI/CD, а второй в инфраструктуру как код. Но это в теории. На практике этим занимаются одни и те же люди, в смысле в одной команде ты делаешь пайплайны, в другой, например, экспортёры для Prometheus. И обеим специализациям нужно уметь в кодинг, или no hire. Сейчас нужны задачи по написанию операторов Kubernetes, по написанию Serverless функций по обслуживанию инфраструктуры. Погуглите термин ChatOps, и учите кодинг, если не хотите завтра оказаться за бортом:
                            И там тебе не будут рвать мозг.

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

                            Уже специальность благодаря хрюшам

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

                            Клёво же. Деньги это хорошо. Ну и не на 20%, имхо.
                              0
                              Разница между DevOps и SRE в том, что первый с уклоном в в CI/CD,

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


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

                              Я вот последние месяца 3 смотрю вакансии. По факту сейчас если ты классический админ, но просто хорошего уровня. То с работой все куда легче и вакансии в разы интереснее. Так что ещё вопрос кто остается за бортом. Ибо хайп порадил столько людей которые занимаются непонятно чем и зачем, что их стало больше чем вакансий. А остальные готовы работать за пятерых, за копейки. Только ради того что бы "обучаться и не остаться за бортом." Что весьма забавно).


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


                              P.S. К слову согласно методологии, не должно быть отдельного человека который будет например, экспортёры для Prometheus делать. Метрики должен должены отдавать сразу разрабы которые делают продукт, ибо никто никто кроме них самих не знает продукт лучше и не знает какие метрики им нужны.
                              C пайплайнами сложнее, но примерно такая же песня по факту. Просто тут ещё и тестировщиков надо подключать.


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

                                +1
                                P.S. К слову согласно методологии, не должно быть отдельного человека который будет например, экспортёры для Prometheus делать

                                Нет разница в том что DevOps это методология.

                                Методология и прочий сферический Agile/Kanban/etc в вакууме отдельно, реальный рынок труда отдельно. В нашей и в куче других контор SRE это кто больше (но не исключительно) пишет тераформ, кубернетес операторы и лямбда функции для инфраструктуры, а DevOps это те, кто пишет врапперы вокруг тест кейсов, проектирует CI/CD пайплайны, соединяет в одно целое ops, dev и qa. Я работала и в качестве SRE(в других компаниях) и DevOps (сейчас и в других конторах). Мне больше нравится DevOps, т.к. не отвечаешь за продакшен, а отвечаешь за пайплайны и другую инфраструктуру для разработки, которые ночью и в выходные не нужны. Обычно DevOps может работать SRE, а SRE девопсом. Собственно, я могу работать и QA, и BackEnd разрабом. А вот одмин, который боится перегружать головку, нет.
                                То с работой все куда легче и вакансии в разы интереснее. Так что ещё вопрос кто остается за бортом

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

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

                                    0
                                    Мне не нравится, что когда ищешь работу, мою специальность могут обозвать как угодно: DevOps, SRE, Build Engineer, Pipeline engineer, а сейчас у меня в тайтле Software Developer (DevOps), как это найти на линкедине или индиде вообще ХЗ, они мне сами написали.
                                    А по факту есть люди-программисты инфраструктуры, со скиллами одминов, разрабов и QA, и это и есть моя специальность. Проблем с количеством офферов, когда я ищу работу у меня никогда не было, как и с тем, чтобы учить новые технологии. Почему Вы боитесь сложных задач я тоже не понимаю.
                                    Специальность мне нравится, но не нравятся некоторые возможные задачи. Например, писать кубернетес операторы или лямбды, или чатботы, или тесты для бэкапов мне нравится, но мне не нравятся овертаймы, которые у админов постоянно и у SRE тоже частенько (если напишут кривой кубернетес оператор, который должен автоматически чинить продакшен).
                                      0

                                      Я просто не считаю эти задачи сложными) А от фраз типо люди-программисты инфраструктуры уже смешно становится. Считаю что писать yaml'ы это обычная работа, обычных админов.


                                      Ничего сложного в том же кубере или промитее нет, для человека который уже лет 5-10 админит что то посложнее серверов про котиков. Как и нет сложности написать экспортер для промитея например на lua или описать инфраструктуру в терраформе.


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


                                      К слову вы не видели наверное какие интересные штуки лет 15 назад админы на перле писали. Там реально были иногда просто офигенные вещи. От которых не знаешь или плакать или восхищаться. И это все равно не делало их программистами. И не говорило о том что они умели программировать.


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


                                      А админ сначала оценит задачу и если что спросит "А зачем это делать, если под вашу нагрузку и требования можно сделать haproxy два сервера и настроить обычный automatic failove за месяц" И это будет работать ещё лет 10-20.

                                        0
                                        Ничего сложного в том же кубере

                                        Хм, как много патчей Вы писали для тех или других Kubernetes операторов?
                                        Может быть, у Вас есть свой оператор, как pet project?

                                        К слову вы не видели наверное какие интересные штуки лет 15 назад админы на перле писали. Там реально были иногда просто офигенные вещи. От которых не знаешь или плакать или восхищаться. И это все равно не делало их программистами. И не говорило о том что они умели программировать.

                                        Мне тоже не нравится говорить «я умею программировать», это очень громкое заявление, если его сделает Ритчи, Керниган, или Гвидо, или Торвальдс, оно будет звучать достаточно весомо. Я предпочитаю считать себя говнокодером-инфраструктурщицей, но проблема в том, что большая часть людей на рынке DevOps/SRE/ops не умеет ничего даже отдалённо похожего.
                                        Причём даже далеко не все backend разработчики знают то, что должны, в общем-то, знать, увы.

                                        Считаю что писать yaml'ы

                                        ХЗ, хз, в последнее время я пишу(пытаясь не говнокодить по-возможности) чаще всего на питоне и голэнге. С yaml'ами я работаю, конечно, но я их скорее создаю, в смысле, структуру yaml'ов для кубернетес оператора, например. А serverless/AWS lambda это вообще не про ямлы, как и chatops подход.

                                        Кстати, terraform'овский диалект вполне себе вещь в себе. Круто, например, что он декларативный (как Puppet). Нет ничего плохого в том, чтобы кодить на декларативных диалектах, это вовсе не стыдная работа, а очень нужная, и требует достаточно глубокие знания, чтобы делать это хорошо и правильно.

                                        Ну или например, берёшь ямлы из банального ансибла, и цепляешь их к утилите через питоновский модуль ansible-runner, и вызываешь из питон кода. Эта утилита вызывается, например, из test suite/CI. Может, это у Вас задачи такие, с «программированием только на ямле», не знаю :(
                                        У меня, например, сейчас задачки по написанию пишу инфраструктурного тулчейна для тех, кто, собственно, пишет код продуктов.

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

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

                                        А админ сначала оценит задачу и если что спросит

                                        И это тоже
                                          0

                                          Ну ясно да. Все что не голенг и не кубер и не свои велосипеды это не "очень профессионально".


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


                                          Звучит как то слишком инфантильно.


                                          Самые забавные задачи были в моей практике на аутсорсе, это когда приходили заказчики и просили Вытащить все из AWS, убрать нафиг CodeDeploy и прочую дичь. И сделать нормально на 5-10 дедик серверах. Ибо они задолбались тонны бабла в это все вливать, без какого то выхлопа. И искать специалистов которые в этом трешаке разберутся. И с каждым годом подобных задач все больше. Люди наигрались в крутые компании "как у гугла".


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

                                            0
                                            Пофиг сколько времени это решение займет. Пофиг сколько денег компании потребует.

                                            Тулчейн для разработчиков даёт очень много денег компании: представьте сотни разработчиков, и сэкономить им час-другой в день — это же офигенно!
                                            А ещё, меня по-настоящему удивляет, что для кого-то написание кода на питоне и голэнге это что-то сложное, нестандартное и трата ресурсов работодателя бесцельная. Странно это. Вы в курсе, например, что сейчас считается правильным подходом автоматизировать ops работу написанием Кубернетес операторов, перенося в них все те инструкции, которые обычно компании имеют, как что-то пофиксить руками (вроде зайти в AWS консольку и ткнуть во что-то, или через ssh и запустить команды, если какая-то специфическая ошибка в логе/мониторинге)?
                                            Мне кажется, люди, для кого писать на ямле легко и быстро, а на питоне(js, golang, итд — хотя бы на одном языке) сложно и долго, просто не нужны на рынке.
                                              0

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


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


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


                                              Я в жизни видал продовые сервера с аптаймом более 10-15 лет. С деплоем через пакеты, haproxy, и bgp. Которые эти 10 лет работают стабильно и ещё столько же проработают.
                                              Вот назовите хоть одну причину, зачем это все тащить в go инфраструктуру и кубер? Или зачем под подобные задачи делать кубер, го скрипты и прочую дичь?

                                                0
                                                Меня удивляет что кто то не понимает что эти костыли и велосипеды нужно поддерживать. Как и любой другой код.

                                                Конечно. А меня удивляет, что кто-то думает, что лапшу в ямле поддерживать проще, чем аккуратный компактный оператор в кубере или лямбда функции. Если же для кого-то на самом деле так, точно профессия была выбрана верно? Может, этому человеку лучше всё-таки в курьеры?

                                                Вот назовите хоть одну причину, зачем это все тащить в go инфраструктуру и кубер?

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

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

                                                А вы читали вообще что я писала? Например, автохилинг через кубернетес операторы: если прод упал ночью, пока кто-то проснётся, пока включит комп, пока запустит VPN, пока разберётся что произошло, и прочитает инструкции, контора может потерять кучу денег. Если есть инструкция, как чинить продакшен, её можно описать в кубернетес операторе.
                                                Да, бывают случаи, не описанные там, но речь, собственно, не о них.
                                                Или, например, юнит-тесты для инфраструктуры, функциональные для бэкапов и дизастер рекавери сценариев — я должна и это объяснять, зачем нужно?

                                                Ещё вы почему-то проигнорировали насчёт chatops: а ведь сейчас девопсы очень часто пишут чат-боты для слака и жиры (на фронтэнде), или для github, gitlab, итд и с инфраструктурой на бэкэнде, и это экономит бэк, фронт, DBA разработчикам кучу времени.
                                                Чат-боты Вы тоже собираетесь «программировать на ямле»?
                                                  0

                                                  Чатопс это круто да. Особенно например в рамках PCI DSS. Нафиг безопасность. Давайте рулить всем из какойто свистелки написанной на коленке).


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


                                                  По факту вся концепция DevOps кладет большой болт на безопасность зачастую. Но подобные чаты это апафиоз раздолбайства.


                                                  Я лично был бы до последнего против этой фигни в проде где что то хоть немного более важное чем фотографии котиков.


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


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


                                                  Это как с экспортерами к промитею. Можно конечно писать свои. Но те которые есть на странице docs/instrumenting/exporters/
                                                  Покрывают 100% требований обычной компании. И потом если что новому человеку с ними разобраться будет в разы легче.

                                                    –2
                                                    Да одна только сертификация

                                                    Всегда сочувствовала тем, кто работает в госпараше. Как вы там боретесь с burn-out'ами? Не скучно?

                                                    К слову про автохилинг. Если у тебя есть проблема которая появляется несколько раз, ты знаешь причины и как её лечить. То какого черта. Почему ты не сделаешь так что бы она не повторялась? Это как раз стандартная работа админа/разраба.

                                                    Есть одна команда, она пишет бэк. Есть другая команда, она пишет инфраструктуру как код. Баги в беке фиксит команда, которая пишет бек, нет? А автохилинг это страховка продакшена от багов в беке. Как и CI/CD и автотесты — часть из которых (юнит) пишет бэк команда сама, а часть QA команда (функциональные, end2end, интеграционные итд)

                                                    То в конце месяца счет очень порадует руководство.

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

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


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


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

                                                        0

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


                                                        Да и будем откровенны, сложилась бы жизнь по другому, родился в другой стране например или просто в другое время. Далеко не факт что пошел бы в IT. Просто для человека рожденного в районе 90х не в МСК выбор был из разряда ты или в IT и получаешь от 25-50 тысяч на старте и до бесконечности в перспективе. Или проектируешь самолеты за 15-30 тысяч всю оставшуюся жизнь.


                                                        Были бы в ИРКУТ хорошие ЗП, я бы скорее всего туда пошел. Все же у нас семейная династия там работала начиная с прапрадеда. И это реально интересно, а не унылое стучание по клавиатуре.

                                                      0

                                                      К слову про автохилинг. Если у тебя есть проблема которая появляется несколько раз, ты знаешь причины и как её лечить. То какого черта. Почему ты не сделаешь так что бы она не повторялась? Это как раз стандартная работа админа/разраба.


                                                      Если проблема неизвестная. То подобные автохилинги, зачастую делают только хуже. Тебе в любом случае нужно понять причину проблемы и дальше уже подумать над решением. А не запускать что попало. Ибо если на тебя идет условный ddos а ты начнешь плодить контейнеры в aws автоматически изза того что у тебя ресурсы заканчиваются. То в конце месяца счет очень порадует руководство. (Это кстати прям топовая ошибка из косяков доморощенных DevOps специалистов, когда они начинают просто плодить контейнеры/виртуалки и прочее под нагрузкой, не смотря причины нагрузки)

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

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


                                                    У кого-то считается правильным автоматизировать работу ops плэйбуками ansible, у кого-то рецептами chef, у кого-то простынями bash или вообще php :)


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


                                                    Я вот взял бы себе в команду "yaml-программиста", чтобы остальную команду вообще "devops" и ops вопросы мало касались. Пускай поднимает Кубернетес, пускай поднимает пайплайны и пишет докерфайлы. Даже операторы пускай использует, но только те, у которых тысячи звёзд на гитхабе. Самописные — нет. Кто в них потом разбираться будет, когда ему у нас станет скучно, а какая-то крупная компания предложит ему позицию разработчика операторов?


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

                                                      –1
                                                      Я вот взял бы себе в команду «yaml-программиста», чтобы остальную команду вообще «devops» и ops вопросы мало касались.
                                                      пускай поднимает пайплайны и пишет докерфайлы. Даже операторы пускай использует, но только те, у которых тысячи звёзд на гитхабе. Самописные — нет.

                                                      Вы тоже не понимаете, что лапша в ямле ничем не лучше лапши в голэнге, питоне, js итд. Она не лучше в вопросах поддержки.
                                                      Ещё раз, компактный оператор на golang куда лучше километровых yaml конфигов, которые писал туповатый чел, боящийся «программирования»
                                                        0

                                                        Чем лапша на ямле хуже лапши на питоне или го?


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


                                                        Мой предел в экосистеме Кубернетес — это adhoc хелм-чарты, которые те же километровые ямлл-конфиги, вернее шаблоны для них с вырвиглазным синтаксисом гоу-шаблонизатора. Мне не место в индустрии, потому что я не хочу глубоко разбираться в личное время с очень узкоспециализированными знаниями и приобретать несильно востребованные в рамках моей основной специализации навыки? А на ямле и обычные конфиги приложений, и CI/CD, и конфигурация серверов, и облака, и куча всего ещё.


                                                        Особенно учитывая, что Кубернетес в обозримом будущем я использовать не буду. AWS или docker swarm — возможно, но k8s маловероятно — хлопотно это.

                                                          0
                                                          Чем лапша на ямле хуже лапши на питоне или го?

                                                          Ничем не лучше. Я сказала, что если задача решается километровым и невнятным, сложно поддерживаемым yaml-конфигом, и оператором на golang (python, etc) в несколько строчек, то нужно выбрать оператор на полноценном языке программирования. А со страхом писать не на ямле можно бороться, например, походами к психологу
                                                        0
                                                        На рынке есть ниша для людей, которые легко и быстро пишут на yaml в рамках популярных продуктов, а на языках общего назначения только в случае крайней необходимости.

                                                        а что значит "писать на yaml"?

                                                          0
                                                          Ansible, Kubernetes, Docker, многие системы CI.
                                                          Все они конфигурятся yaml-писателями :)
                                                            0

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

                                                              0
                                                              Да ладно, я и сам такой yaml-писатель)
                                                              +1

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

                                                                +1
                                                                так конфигурятся или пишутся?
                                                                Даже занудство должно иметь свои пределы)
                                    0

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

                                      0
                                      зачем человек который умеет писать на 2-3 языках пойдет в девопс.
                                      Если можно получать в 2 раза больше работая обычным разрабом.
                                      Это шутка? Обычно девопс получает в 2 раза больше чем обычный разраб.
                                        0

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

                                          +1
                                          По моим наблюдениям и исследованиям в glassdoor девопс всегда больше чем разраб такого же уровня. Возможно зависит от географии, но я беру европу, штаты, израиль.
                                          В два раза конечно вряд ли, но стабильно 10-20% больше.
                                            0
                                            да девопс это и есть разработчик, просто разработчик инфраструктуры(infrastructure-as-code же). Всё зависит от стека. Возьмём веб бэк разработчиков — например, php/ разработчик вордпресс и разработчик Django — очевидно, что у второго зарплата выше.
                                            У девопсов/SRE так же: chatOps, gitOps:kubernetes/golang devops'ы дороже, чем «программисты ямлом на ансибле»
                                            Собственно, DevOps кубернетес стека точно дороже большинства веб-бэк и фронт разработчиков, но сипипишники и Scala разработчики точно дороже.
                                            Если же мы возьмём «девопса» с опытом написания автоматизации на баше, то Django разработчик будет дороже.

                                            Я несколько раз меняла свой стек:
                                            Puppet > Puppet/OpenStack > Puppet/Ansible + Python / OpenStack > CI/CD (написание фреймворков для автотестов итд, дженкинсы, argoCD, итд) + Kubernetes + Golang + Python.
                                            Сейчас тоже самое, только ещё serverless добавился
                                              +1
                                              Ну чтобы избежать разниц между компаниями я просто беру одну в глассдуре, смотрю сколько получают сеньор девопс, потом там же сколько получает сеньор разраб. Обычно девопс получает больше в рамках одной компании.
                                              Очень много «девопс» которые на самом деле все что умеют это разговаривать с амазон апи, по хорошему это просто опсы со знанием клауда, но кому это интересно.
                                              Кубер девопсы тоже разные бывают, есть те которые держат кубер инфраструктуру, а есть те кто только могут деплоить там докер. Естественно первые получают намного больше.
                                              Puppet > Puppet/OpenStack > Puppet/Ansible + Python / OpenStack > CI/CD (написание фреймворков для автотестов итд, дженкинсы, argoCD, итд) + Kubernetes + Golang + Python.
                                              А где работали если не секрет? Очень похоже на мой стек :)
                                    +8

                                    Я вот по себе смотрю: 5-7 лет не работал с сетями и все знания улетучились. Я без жёсткого повторения не порисую строение пакета и разные бинарные/сокральные значения в tcpdump.
                                    Да и за 7 лет второй родной язык забыт — могу понимать, но не говорить :(
                                    А за 10 последних лет в сетях надобность резко сокращается, и в iptables и в прокси серверах и в баше и т.д.
                                    С другой стороны на Амазоне столько штук, что можно докторскую делать по одной — обновления каждый месяц.


                                    Не видно ещё Spark, Flink, Kafka, Hadoop, Storm, Redis, Nginx, DNS( Route53, Akamai, dyn ), CDN.
                                    Блин чего только nginx или Akamai стоит.


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


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

                                      +5
                                      Выключить fsync? Тут надо оговорку давать, что мол ускорить надо любой ценой. А то далеко не каждому человеку беспокоящемуся за данные такой метод в голову придет.
                                        +3
                                        К чему вообще такие выдуманные ситуации? Отключить fsync плохое решение, нужно решать проблему в корне, иначе это «медвежья услуга», особенно для руководителя, который в этом не понимает. Была проблема, пришел «программист», выключил fsync и нету проблемы. Зачем тогда что-то еще делать, ведь все же работает? Так и останется оно с выключенным fsync до определенного момента…
                                          +2
                                          нужно решать проблему в корне

                                          Это не всегда работает. У меня был клиент у которого приложение постоянно убивалось из-за недостатка памяти, в ответ на ествественный совет докупить памяти он упорно отмахивался — "ну рестартанет, не проблема". Приложением было mysqld.

                                            0
                                            Хотя бы посмотреть план выполнения запроса, может там не хватает индекса и СУБД каждый раз перечитывает таблицу с диска.
                                            +1
                                            synchronous_commit = off делает всю грязную работу за тебя, но ты рискуешь не всей базой, а только транзакциями за последние 0,6 сек.
                                            0
                                            Согласен, что простое общение как инженер с инженером больше даст представление о человеке, но все же надо иметь золотую середину. Не допрос же, но знать базу это обязательно
                                              +9
                                              Про корневой протокол

                                              Это что за протокол?
                                                +3
                                                Новичок, не знающий Docker, спокойно в нем разберется, если у него есть понимание, что такое HTTP, TLS и сети

                                                А какая взаимосвязь между http и docker? В смысле как знание http поможет в освоение docker?

                                                  0

                                                  Типичная задача: поднять публичное (читай — https must have) веб-приложения на Докере. Усложнение сам Докер должен удалённо управляться, на сервере есть только он по сути.

                                                    0
                                                    Типичная задача: поднять публичное (читай — https must have) веб-приложения на Докере.
                                                    и как знание http протокола поможет в данной ситуации?

                                                    Усложнение сам Докер должен удалённо управляться, на сервере есть только он по сути.
                                                    Что в вашем понятии управление докером?
                                                      0

                                                      Ну надо понимать что будут идти http запросы, знать про коды возврата, что должны слушаться 80/443 порты, настроить веб-сервера, повесить TSL и т. п.


                                                      Обращение к API Докер демона. Чаще всего CLI клиентом Docker. По дефолту обычно он стучится к локальному серверу, но может и к удалённому

                                                        0

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

                                                          0
                                                          не проще к серверу по ssh подключаться? Ну и так-то думать, что все контейнеры в обязательном порядке крутят что-то связанное с http — в корне не верно
                                                            0

                                                            Вот точно не проще. безопасней возможно, но не проще.


                                                            У самого докер HTTP API.

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

                                                      Вы ведь в курсе, что DNS и по tcp работает? И в большинстве случаев "критичные системы" работают таки по tcp ибо он гарантирует доставку. Например трансфер зон в dns не просто так работает по tcp ;)

                                                        +4
                                                        Не только трансфер зон. Бывают случаи вида. «Тут работает, а тут не работает». У человека проблема была: TXT записи yandex.ru на одном хосте принимались нормально, на соседнем либо пусто, либо connection timeout, no servers could be reached. При этом TXT записи того-же google.com, на этом-же хосте, принимались на ура! Когда цепочка была проверена вплоть до корректности MTU, обратили внимание на скромненькую строчку выдаваемую nslookup… Truncated Retrying in TCP mode. И тут Штирлиц понял, что забыл открыть 53/TCP для этого хоста, на граничном файрволе.
                                                        Протокол DNS использует для работы TCP или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.

                                                        Гугловые TXT записи весили меньше 512 байт и спокойно приходили по UDP, а вот яндексовые уже не влезали.
                                                        +4

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

                                                          +14

                                                          У меня к статье то же недовольство и занудство, что и к 90% вакансий с упоминанием devops, и к лично вашему практикуму, собственно (к практикуму не только это, ну да ладно). Это все чисто инженерные навыки, которые к devops имеют весьма косвенное отношение. Перестаньте лепить ярлык devops на людей, которые просто админят все, что админится. Этим занимаются обычные админы, никаким devops тут и не пахнет. Бд тут вообще ни к селу, ни к городу. Лучше б про мониторинг и логирование темы включили, про гит и ветвление там, да хоть про облака, уж это куда более в тему.
                                                          Как вопросы на собеседование чисто админу, это вполне ок. Не без удовольствия пытался отвечать самому себе, подметил какие-то пробелы (закрывать я их конечно же не буду, пока мне не потребуется это в работе или еще где).


                                                          Разве тебе не любопытно было узнать, как работают все эти штуки, в которых ты тыкаешь курсором мышки?

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

                                                            0

                                                            Полностью согласен.
                                                            DevOps он не только про администрирование.
                                                            Как знание http поможет DevOps оптимизировать процесс выкладывания продукта в AWS Marketplace?
                                                            Ещё есть куча компаний которые отправляют клиенту свой продукт «коробкой» или в магазин приложений.

                                                            +8

                                                            Как-то слабо. А почему нет terraform, k8s, grafana, tsdb на худой конец? Где IPv6? И почему ни слова про http/2 или http/3. Последний, кстати, основан на UDP, так что не надо про критичные сервисы. А ещё не коснулись облачных провайдеров типа GCP или AWS (я уже молчу про специфичные типа Aptible).


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

                                                              0
                                                              Последний, кстати, основан на UDP, так что не надо про критичные сервисы.

                                                              http/3 (если вы про quic) не основан на UDP а использует его в качестве транспорта, в статье же речь шла о "чистом" UDP. Разумеется, если ваше приложение само заботится о гарантиях доставки то хоть голубями можно это делать.

                                                              +2
                                                              И ни слова про DevOps… :(
                                                                +2
                                                                Я так понял, что позиция автора заключается в том, что IT-шник-универсал справится с чем угодно, включая devops, а человек, не имеющий базовых знаний, провалит любую нестандартную задачу, и поэтому не нужен.
                                                                  0
                                                                  Мне тоже так показалось, т.к. большинство вопросов охватывают более широкий спектр специализации, чем devops. Имхо, нормальный веб-разработчик на большую часть этих вопросов тоже ответит. Или админ линуха, или ещё кто-то из it-тусовки. Не только devops.
                                                                    +1
                                                                    Вот только где в вопросах то самое «Dev»?
                                                                    Всё, что перечислил автор, в той или иной степени (всесто докера были начальные системы полной вируализации, потом OpenVZ, lxc… и так далее) было «сисадминством» ещё когда я начинал в нулевые.
                                                                    Скрипты для выполнения рутинных задач писали и раньше, только вместо ныне модного Python — на Perl, tcl, awk… Без разницы какой год, посмотрите на зоопарк утилит в Юникс-компатибильных системах.
                                                                    При этом человек может ответить на все вопросы, а код писать очень плохой (используется эвфемизм к более распространённому эпитету), и толку от него как от девопса, того самого девопса, который может сесть с программистами бэкенда и вместе сделать как надо, будет ноль.
                                                                      0
                                                                      Я думаю, просто автор ошибся с названием статьи. Её следовало назвать примерно так «Базовые знания, которые надо знать, если ты работаешь с Linux и web».
                                                                +9
                                                                Знает ли мой собеседник, что такое MX-запись, как работает spf или как работает DKIM.

                                                                А вы сами точно уверены что знаете как оно работает? Тогда скажите зачем человека расспрашивать о технологиях защиты от подлога электронных писем в SMTP, на вопросах о DNS?

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

                                                                Так вы про Bash спрашиваете, или всё же про кучу других утилит/языков, к Bash имеющих такое-же отношение как и PowerShell?
                                                                А то «распарсить какой-нибудь лог» на чистом баше, это тот ещё кактус пожевать.

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

                                                                Оказывается чтобы разобраться во внутриустройстве докера надо не о принципах работы ядра линукса (и интерфейсов им предоставляемых) иметь предствавление, а о нескольких протоколах из стека TCP/IP.

                                                                Я это на самом деле злорадствую, подражая тону статьи.
                                                                Ваш гайд ультимативный, но точно не по DevOps.
                                                                  +1

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

                                                                  +1
                                                                  Скажите, а гитхаб сосикателя вы смотрите?
                                                                    0

                                                                    Про айноды ещё надо спросить обязательно!

                                                                      0
                                                                      и разницу между ext4 и xfs, ага)
                                                                      0
                                                                      В чем то автор статьи прав, базу знать нужно, но я не считаю что вот прям как алфавит. На вскидку на таком собеседовании я половину ответов на вопросы досконально просто не вспомню. Про те же DKIM и spf записи. В современных реалиях такие вещи используешь на практике редко и значения в голове просто оседают остаточными знаниями. Так что я бы ожидал ответа максимум: «что эти записи создаются для того чтобы тот же gmail не отправлял письма с твоего почтового сервера в спам»

                                                                      Или например про OSI — я помню что там 7 уровней, но на вскидку я их не назову и за что они отвечают.
                                                                        0
                                                                        К сожалению, наличие корректных SPF и DKIM записей на даёт гарантии, что Gmail не отправит ваше письмо в спам. Вероятность попадания в спам уменьшится. У больших бесплатных почтовых хостингов много критериев отсеивания спама, не связанных с этими протоколами.
                                                                          0
                                                                          Я вам более того скажу, наличие правильных SPF, DKIM и даже DMARC (без самой жесткой политики) вам не гарантирует, что Гугл поддельное письмо пошлёт в спам. Просто иконку к нему прилепит, что мол не мог гарантированно проверить отправителя (DMARC fail в хэдэрах). Без шуток.
                                                                            0
                                                                            Коллеги я утрирую теоретическое решение, по факту я с вами полностью согласен.
                                                                        +1
                                                                        Надо знать все юниксовое, все Unix-like системы. Нужно уметь работать с Shell и Bash, знать основные команды. ls-ы всякие, mkdir и т.д.

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

                                                                        Просто: нужно выключить fsync,
                                                                        ну такое, может стоило бы включить логирование долгих запросов и посмотреть какие запросы, например, не используеют индексы? А то ведь от условного запроса вида select * from table1 where field1 like '%some text%' ни один fsync не поможет.

                                                                        А еще разработчики любят писать
                                                                        такое
                                                                        image
                                                                        и потом приходят к тебе и говорят, что ты криво настроил сервер и он все время тормозит. И из-за этого они не успевают во время закрывать тикиты
                                                                          +1
                                                                          Если кандидат сказал бы мне что дальше общаться нет смысла из за моего заданного вопроса то он я ему сказал бы спасибо и пожелал ему удачи, причины возможно следующие:

                                                                          1: Кандидат не знает ответ на вопрос, не хочет говорит об этом, проблема с признанием ишибки/незнания
                                                                          2: У кандидата сильно большое эго он «недостоин» этого вопроса
                                                                          3: Вместо того что бы спокойно ответить и объяснить почему этот вопрос не из его темы отвергает вопрос, проблемы со стабильностью, будет проблемно работать
                                                                          4: Кандидат не понимает что в вакансии описан всегда идеальный кандидат, а люди приходят разные, кто то пишет на баше а кто то давно перепрыгнул это черту, мы знать не можем заранее что у вас с опытом.
                                                                            +1
                                                                            Дело не в эго, и конечно корона с головы у меня не упадет, просто это сразу показывает уровень тех спеца и как правило и уровень фирмы в целом. И естественно дело не в конкретном вопросе, а скорее в уровне самого вопроса. Это из серии как у senior c/c++ developer задать вопрос вида — как объявить массив. Как думаете, что вам ответит на этот вопрос большинство кандидатов?

                                                                            Таким образом я просто экономлю и свое и их время и все довольны. Не вижу смысла в подобных ситуациях тратить свое время. Все же на junior/middle/senior позиции вопросы и их уровень должны отличаться, имхо
                                                                              0

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

                                                                                0

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

                                                                                0

                                                                                Просто есть резюме. Если вам его прочитать лень, то зачем с вами говорить.

                                                                                  0
                                                                                  Вы когда то нанимали людей? Если в резюме все указывали реально что они умеют то мы бы жили в идеальном мире.
                                                                                    0

                                                                                    Нанимал. Смотреть в нем нужно не на то что они умеют. А на то кем и где они работали.


                                                                                    По мне так вопросы из разряда "как пользоваться awk" корректны для студентов без опыта работы, у которых спросить нечего. А с человеком который лет 5-10 работал на хороших должностях и претендует на ЗП от 150 тысяч например. Можно поговорить о том что они делал на прошлых работах и как. А не спрашивать насколько он помнит man'ы, Таненбаума и модель OSI.


                                                                                    Мои лучшие и самые приятные собеседования как соискателя были в формате "есть такая гипотетическая проблема, что ты будешь делать и как её решать". А дальше общение по теме, почему именно так а не по другому и что где смотреть надо.


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

                                                                                      0
                                                                                      То есть для вас если человек вам сказал что «что дальше общаться нет смысла» после того как вы задали вопрос посередине собеседования это нормально?
                                                                                      Причем вопрос был по теме в которой он должен знать. Вы бы порекомендавали этого человека другу в компанию?
                                                                                        +1

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


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


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


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


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

                                                                              +2

                                                                              DevOps != Системный инженер

                                                                                +4
                                                                                А хотя бы 10k$ в месяц вы за это предлагаете? А то если нет — в большинстве случаев вы как работодатель получаете наижирнейший минус в тетради соискателя.
                                                                                  +3
                                                                                  DevOps он разный как и его понимание :)
                                                                                  Что насчет овнерства процесса перехода на короткоживущие ветки в команде, в следствии изменений бизнесс процессов, только не для нового проекта, а для команды которая живет в долгоживущих бранчах уже года 4, а бизнесс процессы поменялись например пол года назад и до всех стало доходить, что дальше так продолжатся не может, а по другому они не умеют? (Не ну я не про тех, кто просто меняет компании и команды в этом случае, кому-то это все равно придеться разгребать)
                                                                                  Экономика разных облаков? Когда лучше в ажуре, а когда лучше в авсе? А когда лучше потратить месяц, но переехать и почему? А может on premise для этого проекта лучше?
                                                                                  Пол команды за ангуляр, а вторая половина за реакт, вставите свои 5 копеек? А с 11 явой в докер лучше? Настолько, что стоит переписать старый кусок с 8й или нет? А стоит ли вписать в проект эластик между бекендом микросервисов в (не суть, мезосе, кубере, да хоть сворме) и клиентским mssql? А вот если надо, что бы переводы на 12 языков шли вместе с релизом который едет по готовности сам по себе в любой момент, то как это может выглядеть? (сейчас оставание 4 недели после релиза, надо не больше дня — какие мысли ?)
                                                                                  Может и не во всех деталях, но в целом представление и понимание о таком надо иметь?
                                                                                  Как насчет умеющего вот это всё в сеть (я если че ex ccnp&ccvp, хоть и забил на ccie) но в конфлю\any wiki он доки не пишет? Возьмете такого?
                                                                                  А что кандидат думает про дейлики? А он кстати знает зачем груминг&планинг вон у тех ребят? А он кстати на них ходит\участвует? Я стараюсь спрашивать, а зачем он в них участвует (если) и как. (ответ на этот вопрос, это не плохо или хорошо, просто дает понимание о взаимодействии и опыте). А у него кстати опыт работы в выделенной команде девопсов на множество команд или он часть команды? А как больше нравится и почему?

                                                                                  Тестовое задание — вы собираетесь апнуть EC2 с продакшен постгресом, напишите письмо не более чем в 200 слов для своей компании, целевая аудитория письма — сапорт инженеры и лидеры команд.
                                                                                  Так долго можно продолжать и это все будет ни про сеть, ни про баш, ни про логгинг, ни про трейсинг ни про модель OSI.
                                                                                  Лично мне кажется, что эти моменты зря пропущены.
                                                                                  А вот для девопсов которые бывает из программистов конвертируются, мне кажется эта статья может помочь выявить стороны, которые стоит изучить :)
                                                                                  И еще я думаю, это прекрасно иллюстрирует то, почему джуниор девопсов не бывает. (где-то на хабре кстати эту мысль прочитал, спасибо тебе неизвестный мне автор).
                                                                                    0
                                                                                    — А с 11 явой в докер лучше? Настолько, что стоит переписать старый кусок с 8й или нет?
                                                                                    — Пол команды за ангуляр, а вторая половина за реакт, вставите свои 5 копеек?
                                                                                    это однозначно не компетенция devops инженера и он не должен знать ответы на подобные вопросы, имхо
                                                                                      +1
                                                                                      Если с Ангуляром/Реактом как конкретными фреймворками я ещё готов согласиться, что это может быть не про девопса, то с Явой, а если быть точным, JVM в докере и приколами с настройкой работы памяти, сборщика мусора, необходимостью заставить эту богодельню уважать cgroup ограничения, проблемой перезагрузок и отдачи данных upstream/downstream перед «смертью» и прилагающимися приколюхами в sidecar в kubernetes pod, это очень даже туда.
                                                                                        0

                                                                                        Т.е. вы можете дать экспертную оценку что вот эти N строк из 1кк надо переписать с 8ки на 11ю и мы получим прирост в X% при запуске в докере?


                                                                                        Не верю ( с )

                                                                                          0

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

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

                                                                                        Мои примеры не для выставления оценки «хорошо\плохо» и тут нет «должен» или «не должен» знать. А для составлении представления об имеющемся опыте и знаниях. И это определенно не ограничиваетя переченем вопросов из этой статьи.
                                                                                          +1
                                                                                          Это компетенции Senior DevOps с уклоном в архитектора.
                                                                                          0

                                                                                          Вот прямо хорошие вопросы!

                                                                                            +1
                                                                                            Тестовое задание — вы собираетесь апнуть EC2 с продакшен постгресом, напишите письмо не более чем в 200 слов для своей компании, целевая аудитория письма — сапорт инженеры и лидеры команд.
                                                                                            Более прекрасного тестового задания ещё не встречал. Браво!
                                                                                            +1
                                                                                            Вопросы на базовые знания звучат стрёмно, кандидат может подумать, что его зовут заниматься системным администрированием, а не девопсом/сре.
                                                                                            То, что вы задаёте вопросы про маску подсети и только в конце начинаете спрашивать про докер, ci/cd и ansible, тоже приводит к таким мыслям.
                                                                                              0

                                                                                              Мне кажется 90% разработчиков которые учились в университете на IT специальности должны ответить по тем сетевым вопросам что в топике. Что такое маска, IP, DNS, ISO уровни, ARP, RIP, это всё впихивается в 1 семестр. И остаточных знаний достаточно. Я вот читая статью и строча этот коммент вспомнил что это такое, хотя учил более 10 лет назад :D

                                                                                                +1

                                                                                                А что такое 127.0.0.1?

                                                                                                  +1
                                                                                                  Представьте себе, что там есть ещё и 127.0.0.2!
                                                                                                  +2
                                                                                                  Я на хабре еще не видел статьи про «какие вопросы нужно задавать на собеседовании» с положительными комментариями по большей мере. Это наверное говорит о ОЧЕНЬ разнообразном подходе к этому вопросу.
                                                                                                    –4
                                                                                                    Еще один раздает советы как нанять yaml программиста со знанием сетей и линукса…
                                                                                                    DevOps тут и не пахнет.

                                                                                                    P.S. За разбор логов вручную — в 2020 принято бить по рукам. Где централизация логов? Где SIEM? Где алертинг? Вот это все…
                                                                                                      0

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

                                                                                                        +1
                                                                                                        Так если потенциальный админ/devops/техинженер не знает как грепом пользоваться, то какой SIEM ему поможет?
                                                                                                          –3
                                                                                                          Тот, в которых это вынесено в визуально-ориентированный интерфейс, например
                                                                                                            0
                                                                                                            Это уже не admin-way
                                                                                                              0
                                                                                                              Почему?
                                                                                                                0
                                                                                                                Какой это админ/техинженер/devops, если в греп он не умеет, а за gui смотреть умеет? Оператор ЭВМ может быть хотели сказать?
                                                                                                        0
                                                                                                        Согласен со многими комментаторами, в статье про DevOps практически ничего. Местами совсем. В недавней статье про DevOps для рекрутеров куда лучше и качественней вопрос рассмотрен.

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

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

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

                                                                                                        Обычная виртуализация, виртуализация через гипервизор.
                                                                                                        Виртуализация через гипервизор — это понятное дело. Бывает первого рода и второго. А что тогда обычная виртуализация? На чём она работает?

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

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

                                                                                                        Просто: нужно выключить fsync, чтобы база не дожидалась записи с данных на диск, а как бы сохраняла.
                                                                                                        Что уже тогда мелочиться? Давайте vacuum отключим и check point сделаем как можно реже, вообще перестанем писать WAL.

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

                                                                                                        Есть ещё масса вопросов, но важен пока один. На какое вознаграждение по ЗП может рассчитывать кандидат после успешного прохождения такого отбора? Предполагаю, ответ на этот вопрос будет интересен многим читателям этой статьи.
                                                                                                          0
                                                                                                          Задавать вопросы весело, но мне интересно, как формируется уровень ЗП, а главное сама ЗП. Вот работает девопс на удалёнке. Не контейнеры же считать и не часы работы. У кого какие подходы с этим?
                                                                                                            0
                                                                                                            Спрос и предложения как раз и формируют. Хотя бывают и исключения, например, недавно предлагали 3к-3.5к в Киеве, сам я из Харькова. И это очень и очень мало.

                                                                                                            Или еще бывают такого вида — зп определяется по результатам собеседования. Таких я сразу отправляю искать счастливчиков дальше
                                                                                                            0
                                                                                                            У меня на девопс позиции спрашивали:
                                                                                                            0) хард левел вопросы на литкоде
                                                                                                            1) вопросы «рюкзака», сортировок и разные задачи с динамическим программированием (все на доске)
                                                                                                            2) закодить «Жизнь» на доске
                                                                                                            3) как менять батарейки в рейдах (я хз до сих пор)
                                                                                                            4) тонкости амазон API
                                                                                                            5) все сервисы амазон и что они делают, и их очень много
                                                                                                            6) вопросы по селениуму
                                                                                                            7) дебильные «логические» задачки, не про люки, но что-то близко
                                                                                                            8) установить джиру на убунту на виртуалке и настроить проект
                                                                                                            9) как вычислить дупликаты во много-гигабайтном файле с малой памятью на машине
                                                                                                            10) составить регексп для IP адреса
                                                                                                            и т.д. и т.п.
                                                                                                            То есть никто толком и не знает что нужно спрашивать, и просто спрашивает что сам знает или вычитал вчера в интернете.
                                                                                                              0

                                                                                                              Как я собеседовал "девопсов":


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

                                                                                                              А фиг знает, что ещё спрашивать: знал бы — мы бы "девопса" не искали, сам бы всё сделал

                                                                                                            Only users with full accounts can post comments. Log in, please.