devops welcome test что это значит

DevOps — автоматизируй всё

Целью статьи является дать основные представления о DevOps и практиках, используемых при этой методологии. Тут не будет сложных терминов, конкретных продуктов и road map внедрения DevOps, но, надеюсь, будет интересно ознакомиться.

Как такового, определения DevOps нет, и все понимают эту методологию по-разному. Декларируемая цель – убрать барьеры между DEVelopment и OPerations. Поэтому часто DevOps понимают как то, что operations, QA и development находятся в одной команде, сидят в одном помещении, проводят общие митинги, общаются. Само по себе сближение и неформальное общение членов команды всегда полезно и уже это может привести к улучшению результатов. Но есть и формальные практики, следование которым позволяет улучшить поставку релизов, а значит и удовлетворение бизнеса.

Здесь описаны следующие:

Структура статьи построена следующим образом: перечислены практики, дано их описание, приведено Бизнес-Значение практики (то, как внедрение этого подхода улучшит жизнь бизнеса) и Измеримость (как можно измерить улучшение). И Бизнес-значение, и Измеримость также взяты из презентаций «DevOps-Fundamentals».

Ну что же, приступим. Процесс разработки и поставки ПО состоит из следующих шагов:

Начинается все с планирования. Планирование релиза, разработки, тестирования, развертывания. Пропустим этот шаг, так как development и operations в этом шаге не задействованы. После того, как разработчик закончил реализацию некоторого участка кода, он сохраняет (commit’ит) его в систему контроля версий. После этого вступает в дело первая практика:

Непрерывная интеграция (Continuous Integration)

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

Собственно, что такое Continuous Integration? Процесс происходит примерно так: разработчик, после того, как завершил свою задачу и отладился, сохраняет свои изменения в рабочюю копию (TFS, SVN, Git). Дальше в действие вступает некий робот (TFS, TeamCity, что-либо еще), отслеживающий изменение рабочей версии. Он видит, что рабочая копия изменилась и запускает сборку проекта. По результатам сборки, оповещается разработчик (и другие заинтересованные лица) о том, прошло все успешно или нет. Оповещение может быть через письмо, сообщение в трее, или отобразиться на web-странице. Таким образом, если сборка прошла с ошибкой, то разработчик сразу же узнает об этом.

Бизнес значение

Измеримость

Автоматическое тестирование (Automated Testing)

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

После того, как сборка собрана, её нужно проверить. Наиболее быстро это можно сделать с помощью автоматических тестов. Для этого используются различные инструменты: это могут быть Unit тесты, UX тесты, интеграционные тесты. Главное условие – они не должны требовать участия человека. С помощью авто-тестов мы сразу получаем информацию о том, есть ли ошибки в нашей сборке. И сразу же можем начать их исправлять, не дожидаясь результатов ручного тестирования.

Бизнес значение

Измеримость

Инфраструктура как код (Infrastructure as Code)

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

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

Привычки (Habits)

Бизнес значение

Измеримость

Непрерывное развертывание (Continuous Deployment)

Непрерывная развертывание – объединение Continuous Integration (непрерывной интеграции) и Continuous Delivery (непрерывной поставки). Это следующий шаг после успешной сборки и успешного прохождения автоматических тестов (и, возможно, установки галочки «сборка готова к развертыванию» ответственным человеком). Если вы уверены в ваших тестах, их наборе и покрытии, при их успешном выполнении запускается автоматическая установка на соответствующую среду, тестовую или продуктовую. Разница между Continuous Integration, Delivery, Deployment хорошо описана тут: http://blogs.atlassian.com/2014/04/practical-continuous-deployment/

Бизнес значение

Измеримость

Управление релизами (Release Management)

Управление релизом заключается в том, что мы определяем формальные критерии, готова ли сборка к установке на соответствующую среду. Примером критериев, по которым сборка готова, и, если они выполняются, автоматически запускается поставка (Continuous Deployment) могут быть:

Бизнес значение

Измеримость

Управление конфигурациями (Configuration Management)

Управление конфигурациями (Configuration Management) — это детальная запись и обновление информации, описывающей ПО и оборудование предприятия. Такая информация обычно включает версии и апдейты, которые были применены к установленному ПО, а также местоположение и сетевые адреса оборудования. ©

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

Бизнес значение

Измеримость

Нагрузочное тестирование (Load Testing)

Нагрузочное тестирование (load testing) — подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству) Wiki

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

Бизнес значение

Измеримость

Мониторинг быстродействия приложения Application Performance Monitoring

Мониторинг быстродействия приложения (application performance management) – это мониторинг и управление быстродействием и доступностью ПО. APM стремится выявлять и диагностировать проблемы быстродействия комплексно, для поддержания ожидаемого уровня обслуживания Wiki

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

Источник

Зачем нужен DevOps и кто такие DevOps-специалисты

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

Какие практики входят в понятие DevOps и зачем они нужны? Чем занимаются DevOps-инженеры и что они должны уметь? На эти и другие вопросы отвечают эксперты из EPAM: Кирилл Сергеев, системный инженер и DevOps-евангелист, и Игорь Бойко, ведущий системный инженер и координатор одной из DevOps-команд компании.

Зачем нужен DevOps?

Раньше между разработчиками и поддержкой (т. н. operations) существовал барьер. Звучит парадоксально, но у них были разные цели и KPI, хотя они и делали общее дело. Целью разработки было как можно быстрее реализовать бизнес-требования и добавить их в работающий продукт. Поддержка отвечала за то, чтобы приложение стабильно работало – а любые изменения ставят стабильность под угрозу. Налицо конфликт интересов – DevOps появился, чтобы его решить.

Что такое DevOps?

Вопрос хороший – и спорный: окончательно в мире об этом пока не договорились. В ЕРАМ считают, что DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.

Кирилл Сергеев: «Разработчики пишут код, тестировщики его проверяют, а администраторы устанавливают финальный продукт на производственное окружение. Долгое время эти части команды были несколько разрознены, а потом появилась идея объединить их общим процессом. Так появились DevOps-практики».

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

В чем состоит суть DevOps-культуры?

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

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

Какие бывают DevOps-практики?

DevOps-практики покрывают все этапы жизненного цикла ПО.

Игорь Бойко: «Идеальный случай – когда мы начинаем использовать DevOps-практики прямо при инициации проекта. Вместе с архитекторами мы планируем, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, выбираем платформу. Сейчас в моде микросервисная архитектура – для нее мы выбираем систему оркестрации: нужно уметь управлять каждым элементом приложения по отдельности и обновлять его независимо от других. Еще одна практика – это “инфраструктура как код”. Так называют подход, при котором инфраструктура проекта создается и управляется при помощи кода, а не через прямое взаимодействие с серверами.

Дальше мы переходим на этап разработки. Здесь одна из крупнейших практик – построение CI/CD: нужно помочь разработчикам интегрировать изменения в продукт быстро, мелкими порциями, чаще и безболезненней. CI/CD покрывает и проверку кода, и заливку мастера в кодовую базу, и разворачивание приложения на тестовых и продуктивных средах.

На этапах CI/CD код проходит через quality gates. С их помощью проверяют, чтобы код, который вышел с рабочей станции разработчика, соответствовал заданным критериям качества. Здесь добавляется юнит- и UI-тестирование. Для быстрого, безболезненного и фокусированного разворачивания продукта можно выбрать подходящий тип деплоймента.

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

Чем полезны DevOps-практики?

Если бы мы писали учебник по современным практикам DevOps, на его первой странице значились бы три пункта: автоматизация, ускорение релиза и быстрая обратная связь от пользователей.

Кирилл Сергеев: «Первое – это автоматизация. Все взаимодействия в команде мы можем автоматизировать: написали код – выкатили – проверили – установили – собрали фидбэк – вернулись в начало. Всё это – автоматически.

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

Третье – это ускорение обратной связи от пользователя. Если у него есть замечания, мы можем сразу же вносить корректировки и тут же обновлять приложение».

Как соотносятся понятия «системный инженер», «билд-инженер» и «DevOps-инженер»?

Они пересекаются, но относятся к немного разным сферам.

Системный инженер в ЕРАМ – это должность. Они бывают разных уровней: от джуниора до chief-специалиста.

Билд-инженер – это скорее роль, которую можно выполнять на проекте. Сейчас так называют людей, ответственных за CI/CD.

DevOps-инженером называют специалиста, который внедряет на проекте DevOps-практики.

Если суммировать всё это, получается примерно следующее: человек в должности системного инженера исполняет на проекте роль билд-инженера и занимается там внедрением DevOps-практик.

Чем именно занимается DevOps-инженер?

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

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

Кирилл Сергеев: «Прежде чем внедрять обновления в продукт, их нужно протестировать на стороннем окружении. Его готовят DevOps-инженеры. Они же насаждают на проекте DevOps-культуру в целом: внедряют DevOps-практики на всех слоях своих проектов. Эти три принципа: автоматизация, упрощение, ускорение – они привносят всюду, куда могут дотянуться».

Что должен знать DevOps-инженер?

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

1. Языки программирования

DevOps-инженеры знают несколько базовых языков для автоматизации и могут, например, сказать программисту: «Давай ты будешь делать установку кода не руками, а с помощью нашего скрипта, который всё автоматизирует? К нему мы подготовим config-файл, его будет удобно читать и тебе, и нам – и мы в любой момент сможем его изменить. А еще мы будем видеть, кто, когда и для чего вносит в него изменения».

DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.

2. Операционные системы

DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.

3. Системы контроля версий

Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.

4. Облачные провайдеры

AWS, Google, Azure – особенно если мы говорим про Windows-направление.

Кирилл Сергеев: «Облачные провайдеры предоставляют нам виртуальные сервера, которые прекрасно ложатся на рельсы CI/CD.

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

5. Системы оркестрации: Docker и Kubernetes

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

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

6. Системы конфигураций: Chef, Ansible, Puppet

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

Какую карьеру может построить DevOps-инженер?

Развиваться можно и горизонтально, и вертикально.

Игорь Бойко: «С точки зрения горизонтального развития, у DevOps-инженеров сейчас самые широкие перспективы. Всё постоянно меняется, и наращивать навыки можно по самым разным направлениям: от систем контроля версий до мониторинга, от управления конфигурациями до баз данных.

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

Как стать DevOps-инженером?

А также можно посмотреть актуальные тренинги по DevOps на сайте Тренинг-центра EPAM.

Больше информации о DevOps-направлении на сайте.

Источник

Собеседование в DevOps Engineering, как оценить свой опыт и сколько нужно знать?

Основное про DevOps и про обязанности

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

Основные практики DevOps это:

Infrastructure as Code

Некоторые практики разделяются между инженерами, например, QA может отвечать за Continuous Testing а Security за Continuous Monitoring. Как правило, инженер, который получил роль DevOps (не принято говорить «DevOps инженер», но рынок уже взял в оборот, звучит так же неопределенно, как «Scrum инженер») отвечает за все, что происходит с момента, как команда разработки пушнула код в репозиторий или выпустила релиз. Т.е за CI/CD пайплайны, энвайрменты проекта и базовый мониторинг.

Сколько инструментов в домене DevOps и что именно нужно знать?

В области технической экспертизы DevOps возникает вопрос: что именно выбирать, сколько вообще инструментов нужно знать и что показывать на собеседовании?

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

Какое количество инструментов/платформ и насколько глубоко вам нужно знать

Чтобы облегчить задачу выбора, все инструменты DevOps можно поделить на домены:

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

IaC: Terraform

CM: Ansible

Cloud: AWS

CI/CD: CircleCI

Scripting: Python, Bash

Containerization: Kubernetes

Monitoring: ELK, Prometheus

OS: Linux

SQL: Postgres, MongoDB

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

*эти категории можно критиковать в комментариях, это позволит выработать более точную модель!!

Теперь получилась следующая матрица:

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

Можно указать уровень владения в CV, но я бы рекомендовал выделять основные инструменты, с которыми работаете на проекте, и отдельной строкой категорию Novice. Это нужно для того, чтобы состоялся разговор по конкретному опыту.

Тут можно добавить еще один уровень оценки: если вы претендуете на позицию Senior DevOps Engineer, нужно владеть 3-4 инструментами на Advanced уровне и одним инструментом как Expert. Для Middle DevOps достаточно работать с 2-3 на Advanced.

Итого, ваша матрица компетенций:

Middle DevOps Engineer

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

Источник

Ультимативный гайд по собеседованию 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, на понимание того, как работают сети

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

Затем я спрашиваю по всем уровням модели 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-шнике?

Перехожу к 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. Задаю вопросы про индексы, может ли соискатель настроить реплику, может ли настроить логическую репликацию между табличками или просто данными. А что он будет мониторить в этом случае? А как ускорить базу?

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

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

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

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

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

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

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

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

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

Источник