СОБЕСЕДОВАНИЕ Middle DevOps инженера. Часть 1. Теория DevOps и SRE

Подготовка к собеседованию на DevOps

Транскрипция видео:

  • Всем привет Меня зовут Андрей я уже 5 лет работаю инженером в компанию собственный Анти инфраструктуры и встаёт В определённых команд общий мой стаж работы войти уже оставляет порядка 8 лет Всем привет Я работаю в эти больше 5 лет начинал сентейства с админы сейчас инженеры крупные компании здравствуйте А я Антон Павленко и сегодня ты увидишь собеседование Metal devops инженера Я знаю тебе интересно поэтому наливай приятный для организма жидкость усаживайся поудобнее погружаемся в мир собеседование не

    00:00:00 - 00:01:15

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

    00:00:41 - 00:01:46

  • повышенной надежностью и сервера с большими дисками до 5000 ГБ переходи по ссылке в описании ознакамливайся с предложениями там тебя ждет 25 процентная скидка на первый заказ и Андрей тогда я предлагаю начать с теоретической такой части по методологии devops и sere Андрей Скажи пожалуйста что такое дефопс как-то его понимаешь бобс это методология направленная на повышение скорости и качества доставки изменения продукта сквозь весь конвейер производства достигаем за счет тесного взаимодействия команд друг с другом

    00:01:13 - 00:02:45

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

    00:02:00 - 00:03:20

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

    00:02:42 - 00:04:11

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

    00:03:26 - 00:04:56

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

    00:04:14 - 00:06:02

  • приходилось выпустить новый релиз флажок он садился и получаться делом нужно действовать до того как команде был сервис и сборки были производились хорошо Андрей мы как раз таки переходим к следующему вопросу о практиках нужно Delivery там еще есть картофель Деливери континиус дипломин То есть я начну вся это неприемная интеграция интеграция это практика которая позволяет снять с командой разработки необходимость думать о том как же из того исходного кода который они написали получить артефакты продукта которые пойдут дальше

    00:05:11 - 00:06:48

  • Каким бы продукт не был стоп или Каким бы еще летом для встраиваемых систем задача разработчика отправить изменения в систему контроля версии А дальше уже вся инструменты необходимым образом их проверяют проверка физический анализ кода там лендинг это необходимости прогон тестов чтобы это не было автоматически дальше сборка артефакта и в конечном счете артефакт попадает в некое хранилище этих артефактов это может быть облачно Это может быть некое хранилище для компании это может быть даже просто файловая шара

    00:06:13 - 00:07:34

  • куда складываются Zip архивы там зависимости от компании реализации и процесс перевода собранного артефакта с Агента сборки на место для хранилища этих артефактов является доставка артефактов агентом сборки уже постоянно хранилище Чем отличается тем что в дипломед это уже действие когда собраны артефакт попадает в продакшн эксплуатацию в том что компания считает что у них процессы отстроены достаточно хорошо чтобы релиз который вышел сразу без чего либо решения автоматом выкатывался Production подал

    00:07:02 - 00:08:41

  • конечном пользователям при отсутствии делили То есть неразвертывание просто дипломмент просто на стадии в Деливери там уже есть специальный человек который принимает решение выкатывать или нет В целом Да хорошо Так мы Окей мы обсудили практику devops 1 Какие еще практики dobs Ты знаешь очень важно практика инфраструктура как кот инфракрасный заход это на мой взгляд самая базовая необходимая вещь то есть задача практики чтобы результат работы всех команд хранились в текстовом виде надзором системы контроля версии 7

    00:07:58 - 00:09:50

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

    00:08:56 - 00:10:35

  • клиент серверную архитектуру и у него есть на самом деле он не проигрывает YouTube одни ворота просто у него фичи которые на момент создания были более актуальные и сейчас компании которые пользуются содержимом Я имел честь компании просто переводить компанию с обершиным на гитаре нет объективных бизнес причин это нет никакой необходимости и еще до Саб вершин был cvs который опять-таки моя прошла компания успела тоже внедрить И потом заменить на вершину практики Задача в том чтобы все команды команды разработки команды эксплуатации

    00:09:53 - 00:11:15

  • другие хранили свои конфигурации исходные коды под контролем версии я застал тех разработчиков которые упорно не хотели коммитить свой прекрасный код репозитории и потом разработчик уходит или Он в отпуске и у нас проблема в эксплуатации мы не понимаем Из каких исходников была собрана эта программа и не можем быстро подправить одну буквально там константу чтобы оно все работало практики Все изменения [музыка] [музыка] пути жизни продукта и носить в него Да очень объемно ответил но все по делам Ну и назови пожалуйста тогда инструменты

    00:10:45 - 00:12:29

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

    00:12:29 - 00:14:14

  • [музыка] переключать облачных провайдеров с минимальными конфигурация под конкретного провайдера но в целом знаю староформ можно работать со многими аппаратами еще есть решение от adbles которое работает только с WS но понятное дело Это его и ограничение что не получится работать с другими облачными провайдерами также я слышал что есть уже аналог форм который тоже популярность но я с ним не работал про него ничего не слышал и Суть в том что форм файлах можно описать и виртуальной машины с какими ресурсами какими сетями С какими

    00:13:27 - 00:14:57

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

    00:14:16 - 00:15:55

  • было ничего Первое что я сделал Я взял базовый образ операционной системы написал инструкцию Вики о том как из базового образа получить из базового образа всем получить базовый образ моей компании для нашего окружения дальше шагам это все было дальше образ был сохранен в ИЗО файл потом уже из этого файлы следующим Арену выходит инструменты по настройке виртуальных машин которые позволяют из базовой виртуальной машины подготовить уже ту машину я это у нас есть конфигурация по настройке себя сервера и

    00:15:05 - 00:16:47

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

    00:16:03 - 00:17:44

  • наши коллеги которые будут потом поддерживать машину они не будут переживать что из 20 агентов Все ли у них одинаково они будут знать что если все было настроено через систему конфигурирования то все правки содержатся у нас репозитории и можем смело взять и эти практики раскатывать Если вдруг какой-то Агент выглядит испорченным то преследование практика мы легко можем этот Агент просто удалить и создать виртуальную машину заново из шаблона который мы получили шаги применить к ней всем конфигурация

    00:17:10 - 00:18:28

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

    00:17:48 - 00:19:19

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

    00:18:36 - 00:20:08

  • была она показывает себя наиболее часто применимые наиболее простой когда тот момент когда мы считаем что у нас появились справки Мы в этот момент их нужно не кусками разливаем сервером и получаем тут же отчет о том были какие-то изменения если были то какие были они успешными и мы уже знаем что гарантированно да Хорошо согласен вообще как работает ansible ну вообще его этапы работы ну то есть формирование все вот этого делать если говорить поверхностно то есть очень много людей Зачем мне антибал

    00:19:21 - 00:20:53

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

    00:20:11 - 00:21:42

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

    00:21:10 - 00:22:37

  • что он подключается по ssh формировать Да на питоне ложат вот в домашнюю директорию куда-то временные файлы Да и выполняет туда Окей но я думаю в принципе с практиками допс все давай перейдем я хотел тебя спросить знаешь ли ты что такое сырье и вообще чем он отличается это практика цель которой обеспечить максимально Сколь угодно возможно доступность сервиса для клиентов в условиях реальной эксплуатации гарантировать что клиент может пользоваться сервисом в течение персентиля времени он 999 процентов кажется что такой большое

    00:22:01 - 00:23:38

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

    00:23:01 - 00:24:37

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

    00:24:07 - 00:25:52

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

    00:25:02 - 00:26:43

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

    00:25:56 - 00:27:35

  • задача наша Ну вообще it это как бы предоставление доступа пользователей непрерывного Вот ну как бы задача как раз и инженеры обеспечить надёжностью вот этого всего делать Ну ладно это лирика Давайте дальше Окей Мы с тобой уже начали говорить вернее ты начал говорить о методиках показателях так вот что такое я детально не разбирался в отличиях как они правильно расшифровываются я могу сказать что чаще всего встречается среди всех остальных для для вот другие я точно не отвечу я понял что Антона есть прекрасное видео на эту тему

    00:26:57 - 00:28:31

  • но я его смотрел немножко вскользь и не осознал эти метрики их отличия между собой Ну насколько я их понимаю что slay это соглашение между клиентом и компанией о том какой как раз таки допустимое вот это вот надежность мы будем предоставлять сервиса Slow это соглашение уже внутри компании Она обычно выше чем для того чтобы мы будем стараться выполнить чтобы не краски не нарушить свои уже с клиентом это как раз таки индикатор То есть это показатель доступности сервиса который используется для SL и слов

    00:28:12 - 00:29:43

  • наш внутренний по сути это что мы уже выполнили вот остальные метрики это соглашение обычно слайдов Техническая Метрика а slo SL это пороги срабатывания не скорее не пороги а соглашение именно соглашение то что мы говорим что вот Мы готовы это выполнить по сути мы говорим столько-то девяток например вот Мы готовы вам предоставить работать вот Окей Спасибо Да еще есть такое понятие такая же факультативная это бюджет ошибок слышал что-нибудь об этом Ну такой термине не слышал но я могу предположить что

    00:29:06 - 00:30:51

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

    00:30:06 - 00:31:30

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

    00:30:58 - 00:32:18

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

    00:31:39 - 00:32:52

  • финансово все ссылки будут в описании увидимся

    00:32:17 - 00:32:25

Менторы

Специалисты своей области, которые смогут помочь вам

  • Нигма Нурия
    Нигма Нурия

    Middle .Net Developer

  • Сущенко Татьяна
    Сущенко Татьяна

    Senior Product Manager

  • Гудков Денис
    Гудков Денис

    Middle Python Developer

  • Курочкин Константин
    Курочкин Константин

    Ведущий программист

  • Гудман Макс
    Гудман Макс

    Backend Software Engineer (PHP)

  • Гребенкин Антон
    Гребенкин Антон

    Senior .NET/C# developer

  • Ахназаров Фёдор
    Ахназаров Фёдор

    Middle DevOps Engineer | Tbilisi, Georgia

  • Шорохов Дмитрий
    Шорохов Дмитрий

    Middle C# .NET

  • Жуков Александр
    Жуков Александр

    Senior PHP-разработчик

  • Мазикин Павел
    Мазикин Павел

    Middle python developer

© 2024 HireGuru. Сделано в Санкт-Петербурге с hireguru.ru