Здесь переводится видео в статью Александра Титова из Экспресс 42 "Что такое DevOps"
Ссылка на видеодоклад https://www.youtube.com/watch?v=php6DfXXG0Y
Текст сделан из субтитров. Буду очень благодарен в форматировании текста, его вычитки. Для этого достаточно знать русский язык. Присылайте свои pull request или присылайте текст на почту patsev.anton[собака]gmail.com
наверняка всем известно что такое devops рассудок те кто знаешь devops пытаясь это википедия перед конференцией но дело в том что история такая что с самим определением все очень сложно поэтому приходится как бы запускать дискуссию заново что такое devops каждый раз конечно я сам не знаешь и такое вот но мы просто как бы запустим разговор об этом и я немножко как бы своим опытом поделюсь вот и долго думал как сделать про мой рассказ полезным поэтому в рассказе будет много вопросов ну то есть как бы прос которая сам себе задаю которое задаю там клиентом нашей компании и отвечая на эти вопросы иногда становятся в понимании чем-то лучше поэтому вот об этом будем говорить давайте немножко про себя расскажу у меня история такая что я какой-то момент погулял по волнам слияний и поглощений я поработал начали маленьком стартапе клип потому купила бы чуть побольше компания skype новость о к чуть побольше компания microsoft купила skype и в этот момент мне стало доступно увидеть как трансформируется представление живописи в разных по величине компаниях и после этого мне стало интересно уже с точки зрения рынка смотреть на devops и мы с коллегами организовали компании экспресс 42 и собственно уже 6 лет по волнам рынка и и движемся еще кроме всего прочего я организатор один из организаторов в сообщество devops маску это вот там такая черненькая штучка и организатор де опыта из москва 2017 1017 организован немножечко про express 42 собственно мы работаем с такими компаниями проращиванием там диво посмотрим как это происходит делаем выводы анализируем рассказываем всем обучаем людей как быть с практикам в общем всячески растим в этом смысле опыта экспертизу ну давайте немножечко чем доклад да то есть я расскажу зачем нужен devops моей точки зрения что такое devops моей точки зрения и как понять что вы движетесь diablo моей точки зрения но как бы вот этот последний пункт это будет через вопросы то есть как бы я буду себе за вопросы задавайте вы себе быть вопросы задавать соответственно можете например понять как бы компании ваши движется где о вас вы движетесь где опус или что-то в чем то есть проблема ну опять-таки как бы приветствует flame наброс и поймать меня в потом вот дискуссионный комнате я представился как комната лизе куцый докладчиков и рассказать мне что такое devops на самом деле итак первый вопрос который преследует всех и всегда это вопрос зачем многие как бы считаю что de vous это просто какая-то автоматизация или какая-то такая штука которая на самом деле в каждой компании было уже вот у нас был can then send играешь надо знать что уже был devops и как бы иначе как вообще все это ботва нужно пацаны там что-то за границы и развлекаются нам работать мешают вот на самом деле как бы уже стало понятно сейчас что это все-таки не маркетинговый bull sheet вот за сколько там за уже 9 лет развитие сообщества и методологии но все-таки не до конца понятно зачем как у любого инструмента как у любого процесса есть конкретная цель конкретные задачи которые devops в итоге риш соответственно все это связано с тем что как бы мир меняется вот подхода enterprise нова когда компания движется сразу прямо к мечте как пел питерский classic ну вот из точки а в точку б по определенной стратегии вот не определенные для этого структура построено вот и в этом подходе принципе а идти не должно быть должно быть именно под этот подход и построен то здесь эти используется исключительно для автоматизации процессов и автоматизации она не сильно часто меняется потому что когда у вас компания идет по наряженный клиент что там принципе менять работает не трогай сейчас мы немного сейчас мире как бы подход меняется и то что называется таким словом а джоэл на самом деле говорит о том что точки б конечные сразу не видно компания когда идет по рынку работая с клиентом она постоянно исследуют рынок постоянным меняет эту конечную точку б я причем как бы чем чаще она меняет свое направление тем более она в итоге успешно потому что больше рыночных ниш себе выбирает но это можно сейчас например продемонстрировать есть такая прикольная компания вот недавно узнал называется ван бакшеев компания сделала просто бритву и всякие бритвенные принадлежности по подписке при этом они вот эту всю коробочка умеют кастомизировать под разных разных клиентов ну понятное дело что там определенные софт этим занимается который потом отправляет заказ рискую фабрику которая вот эту штуку выпускает так вот вот эта штука была куплена компании unilever за 1 миллиард и сейчас конкурирует жилетом то есть она уже лето на американском рынке значительную долю рынка отожрал а они говорят что как бы ребят новые силы серьезно 4 лезвия нафиг это вам надо это никак не улучшает качество бритья специально подобранный крем чик специально подобранная там вот это вот отдушка и нормально сделано 2 лезвия бритва на самом деле решает гораздо больше вопросов чем эти грёбаные 4 лезвия у джиллетт вот так мир меняется но они собственно заявляет потому что как бы у них есть [музыка] крутая эти системы которая позволяет это делать соответственно как это выглядит в итоге да это выглядит в парами китай там туман kitkat которому уже кто только не говорил но смысл time to market это не как часто мы тепло и мся потому что можно часто тепло из но при этом разные циклы будут длинными то есть можно трехмесячные релизные циклы как бы накладывать друг на друга сдвигая на недельку получаешь у компании как будто бы depois раз в неделю она самом деле от идеи до конечной реализации проходят три месяца так вот тайм ту маркета про минимизацию времени от идеи до конечной реализации потому что есть вот вас есть рынок и с ним взаимодействует программного обеспечения а вот собственно у ван бакшеев собственно сайтик с клиентом взаимодействует нету людей нет продавцов просто сайт где ты кликаешь оставляешь свои пожелания там и так далее вот и соответственно на сайте надо постоянно вычитывать что-то новое постоянно его обновляясь соответствии с пожеланиями клиентов ну понимаете даже наверное южной кореи бреются не так как россии и им нравится там не запах сосны в этой там отдушки там я не знаю запаха селедки внезапно но и соответственно либо им надо быстренько быстренько это дело менять и поэтому разработка по очень сильно меняется то есть через полом и мы должны узнавать очень хочет клиент то есть есть раньше мы какими-то обходными путями узнавали о чем хочется приедут менеджмент бизнес потом он рассказывает мы это как бы проектируем войти систему закладываем как бы крутяк становится то есть час программное обеспечение проектируется всеми кто включен процесс в том числе инженерами потому что инженеры узнают через технические характеристики как как рынок работает и они тоже делятся с бизнесом какими-то своими сайтами например компании клик мы внезапно узнали что люди мы не не изначально не задумывались это нашем приложении что люди вот и людям очень нравится загружать контакт-лист и на сервер и они положили нам приложу hу вот классической компании бы все бы подумали что это бага ну так как это в пекине было написано что это должно как бы классно работать вот это вообще было реализовано так на коленке но была в обычной компании сказать что это бага выключили бы эту фичу ее сказались как бы на фиг никому не нужна самое главное что основная функционале сработает так как бы технологическая компания в этом видит возможность и начинает менять софт согласии с этим 68 году прозорливый парень новинка в conway вот заметил что для того чтобы производить систему другого типа надо еще вдобавок иметь коммуникационную структуру внутри компании другого типа то есть если у вас коммутационная структуры так как бы верхняя иерархическая то это не позволит вам делать система которая принципе вот такое вот могут могут обеспечивать очень высокий показатель танту market вычитать можно по ссылочкам вот про этот закон о он очень важный для того чтобы понимать как это говорят культуру devops или философии девалась потому что на самом деле единственное что как бы базово что меняется как devops это именно структуры коммуникации между командами ну и соответственно с точки зрения процесса вот это как бы процесс до devops то есть начали у нас аналитика происходит потом разработка потом тестирование потом эксплуатацию а как бы devops это когда все эти процессы происходят одновременно и таким образом собственно этот тенту market только и может выполняться взять людей которые работали в старом процессе это выглядит несколько космический и ну так себе вообще скажите пожалуйста а ту у кого технологические компании вы считаете что от вас процесс и одновременно происходит разработки сбора требований стерни эксплуатации классно мне кажется всем всем остальным будет очень-очень-очень сегодняшней конференции очень полезно ну давайте подрезюмируем первую часть как бы зачем нужен devops он нужен для разработки цифровых продуктов если у вас в компании нет цифрового продукта где вы просто не нужен это очень важно devops преодолевая скоростные ограничения последовательной схемы производства то есть когда вы сделали другое сделали 3 сделать четвертое сделали тотемов сделает вот он просто преодолевает эти штуки а с devops увеличивается сложность то есть когда нам рассказывают что не знаю devops евангелисты то что вот у вас будет devops и он станет проще выпускать в отправлении это бредятина он там все сложнее вот становится ману на стенде авито можете посмотреть что такое за деплоить докер-контейнер вообще как бы не реальная задача на этой воде вот эти там ну вот это сделать это реально так то есть сложность становится запредельно до жонглировать многими-многими шариками одновременно и devops меняет полностью процесс организацию компании ну точнее как бы не devops меняет а вот именно этот цифровой продукт меняет а полностью процесс организации в компании а ну для того чтобы вам devops прийти надо все-таки этот процесс полностью поменять и это на самом деле так соответственно вопросы которые вы можете себе задать там работая в компании развиваясь как специалиста да есть у вашей компании стратегии по созданию цифрового продуктов если есть это уже хорошо это значит что ваш компании движется что andi vax и создает ли ваша компания цифровой продукт это значит что вы уже еще на ступеньку выше можете подняться более интересными штуками заниматься с точки зрения devops опять-таки только с этой точки зрения говорю и если ваша компания один из лидеров рынка в нише с цифровым продуктом то скорее всего это вот spotify индекс бубер и так далее то есть этого компании которые находятся на пике технологического прогресса в данный момент соответственно вы можете сидеть вопросы задать если ответы на эти вопросы нет все то возможно вам и не стоит этим заниматься если вам реально интересно как бы что на сегодня будет на конференции то возможно как бы круто просто перейти в другую компанию и начать работать соответственно если как бы нет то компания которая хочет пойти в devops она напоминает этого жалко этого прекрасного носорожек а который никогда не изменится как я уже сказал да что по закону канвы в компании меняется организация и я начну с того что мешает devops у проникать внутрь компании то есть именно с точки зрения организации есть такая штука на английском языке она называется силу русском языке переводит колодцы но смысл этой проблемы в том что между командами не происходит обмен информацией и каждая команда капает свою экспертизу вглубь при этом не строят общую карту в которой можно ориентироваться чем-то это напоминает человека который только приехал в москву еще не знает как ориентироваться по карте метро вот то есть есть например москвич который прекрасно ориентируется своем районе вот а по всей москве он ориентируется по карте не трогать ну как бы вот от этого метро мне столько надо пройти вот а когда ты приезжаешь маску 1 раз да у тебя нет этого навыка и ты просто вот дезориентирован соответственно как бы что первым делом предлагает devops да вот пройти эту этот момент дезориентации и построить общую карту взаимодействия всем подразделениям месте на самом деле этому мешает два фактора первый фактор это следствие корпоративной системы управления что она так построена отдельными иерархическими колодцами она так управляется и есть например [музыка] определенный китаев компания которая вот эту вот систему поддерживают а другой стороны это собственно мозги человека вот эти и ему сложно выйти за пределы своей экспертизы и по ориентироваться но это просто такая вот некомфортная штука представьте себе вы попали я не знаю в аэропорт аэропорт бангкока но был в аэропорту бангкока вот там her сориентируешься в общем то но ты тоже видишь прошаренный наверное очень сложно сориентироваться и поэтому как бы люди люди не выходят не стараются так не делать и до какого ряда не вот оттуда ехать это надо по проводника найти вот соответственно такая же штука происходит в организациях ну самое главное что проблема колодцев для инженера которой ну проникся духом devops и начиталась фаулера начиталась кучу книжек она выражается в том что колодцы не позволяют делать очевидные вещи ну то есть вот люди под ну как мы часто там собираемся на после devops мозг и друг друга мы разговариваем люди жалуются что вот мы хотели он просто как бы чайку запустить а получилось что менеджмент это не надо и р-н это именно как бы из за этого происходит потому что чайка на находим как бы находится на границе многих экспертиз вот и там candy delivery процессом и просто как бы не преодолев вот эту вот проблему колодцев на организационном уровне не получается продвинуться дальше чтобы вы ни делали как бы это грустно не было вот типичные колодцы организациях они показаны на этом слайде то есть разработчики бэг-энда разработчики фронтэнда из тестирование детей эксплуатация сеть и вот они каждый клыка поют свою сторону а общей карты не имеет никто ну кроме там управленцы который как ты их обозревает и управляет там методом разделяй и властвуй вот соответственно они там борются за какие-то звездочки за флажки каждый капает свою экспертизу но в итоге очень когда появляется задача давайте мы все это соединим вместе построим общей pipeline за звездочки уже у бороться не надо за флешки бороться не надо хочу делать вообще это как-то надо договариваться а как никто как бы школе не учил договариваться мы как бы еще со школы наученным там 8 класс o гappu сравни сильным класом ну как бы вот здесь такая же штука происходит вот у кого в компании есть такая тема мне кажется что вы мне что-то недоговаривать соответственно какие вопросы можно себе задать чтобы проверить и если такая тема пользователи команда в общем инструментами носят ли вклад в изменение этих общих инструментов на сколько часто команды перри формируются ну то есть одни специалисты с одной команды перехода в другую команду потому что как бы вот именно в devops редеет становится ну нормально потому что иногда человек просто не может понять чем занимается другая зона экспертизы она он переходит в другой отдел две недельки поработать для того чтобы создать для себя вот эту карту ориентации так можно взаимодействие с этим делом можно ли внутри компании создать комитет по изменение чьего-либо и что-то изменить или для этого нужна сильная рука у руководства самого высшего нужно написать распоряжении недавно я звуки написал про один малоизвестный банк как он через распоряжении внедряет инструменты написали сближение год внедряем как там все происходит вот и насколько мощна у вас для менеджеров получать личные достижения без учета достижений компании как бы если есть как бы это ну если вы на себя ответить на эти вопросы вот сейчас стало понятней есть у вас такая проблема компании или не прояснилась очередь я был настроен на искренний разговор с вами сегодня а ну-ка быстро настя никто не отменял даже во сне соответственно бой стал как это проблема по пройдена первая важная практика в гипсе которые без которой сложно тоже продвинуться дальше это инфраструктурой как кот и чаще всего инфраструктур воспринимают как я не знаю давайте как бы на все за автоматизируем на баше как бы помажем скриптами чтобы огненной было меньше ручной работы вот на самом деле это совсем не так и инсульту рука код она подразумевает что вы то айти систему с которой вы работаете вы описываете виде кода для того чтобы постоянно понимать ее состояние о сути дела вы создаете совместно с другими командами ту карту виде кода который всем будет понятно по которой можно ориентироваться навигировать и так далее то есть дизайне цена самом деле на чем это сделано то есть это может быть ненашев салти написано да это можно яму файл в кубер найтись и делать вот не помню всего не ли завтра коллега из дубль гиса будет как раз рассказывать о том как они сделали свою внутреннюю штуку клику бернейс который вот это все описывает описывает как у них устроены отдельные системы и вот им для того чтобы описать 500 систем нужно можно было сделать отдельный инструмент который описание генерирует и соответственно когда у вас есть это описание вы каждый может вы можете сверяться друг с другом как бы врачом ним меняется как его поменять как вы улучшить что чего не хватает и так далее и ну согласитесь да когда у вас отдельный баш скрипты написаны то как бы обычно это не дает этого понимание у нас даже в одной в одной из компаний где работа у нас было такое название в райтон ли скрипты человеках написала прочитать их уже невозможно вот я думаю что как будто же знакомая штук соответственно индустар как вот это код который описывает актуальное состояние инфраструктуры на этим над этим кодом совместно работают разные-разные-разные разные команды и самое главное что разные разные команды должны понимать учетом как это все работает код сопровождается согласно практикам разработки кадре view xp programming там попурри квесты continuous integration in future кода это все как бы угодно все можно использовать по сути дела код становится общим языком для всех инженеров изменение иисус туров коде не занимает много времени и до сих ничего в нужном коде тоже может быть технический долг такой такое бывает обычно команды сталкиваются с этим года через полтора пустого как они начали внедрять инфраструктуру как кот кавычках виде куча скриптов или даже видя ansi было которого не пишет увидеть спагетти кот такой ну вот еще баш скрипта подкидывают стопочку соответственно как бы важная важная штука если вы еще не попробовали этот парень-то запомни такую штуку что а если бы это не бар немного внимательнее читать документацию и что вообще про это пишут соответственно либо инсульт турка код это про разделение вот этого инфекционного кода на отдельные слои их может быть больше но базового мы вот у себя компании выделяем такие три слоя как они очень понятные очень простые вот ее можно прям вот смотреть на ваш инфу струну коты выставить вот здесь у меня этот слой или нет ни какие слои не выделяются то надо при factory немножко выделить это время соответственно базовый слой это как настраивается операционная система бэкапы там какие то такие вот низкоуровневые штуки там обернитесь разворачивается например на базовом уровне вот есть уровень сервисов то этот сервис который вы даете разработчику это может быть логирование как сервис мониторинг как сервис там база данных как сервис балансировщик как сервис очередь как сервис continues delivery как сервис ну и так далее то есть кучу-кучу-кучу куча сервисов которые отдельные команды могут предоставлять разработки и это все отдельными модуль caminada внутри вашей вашу систему про лень конфигураций описывать и как бы 3 слоя собственный слой где делается при кришна описывается как publications будет поверх вот этой вот этих вот двух слоев разворачиваться соответственно контрольный вопрос в голову есть ли у вас общие нфл стороны репозитории в компании контролируете ли вы технически долг в инфраструктуре используете ли вы практике какие-либо разработки в искусственном репозитории и нарезана ли ваши на струну эту струну на слои можно по дверец а вот этой картинкой sbs сервисов и насколько сложно внести вашу просторный код изменения если вы сталкивались с тем что внесение изменений а занимала полтора дня ну это значит что у вас появился технический долг с ним надо поработать и вы как раз наткнулись на те грабли технического долго культурным кодом я про много таких историй помню когда но чтобы поменять какой-нибудь из цельного переписать половину инфраструктурного кода потому что вот творческие люди творчества и желание автоматизировать все сделал так что там и здесь уже каркас живность ручки убраны и нужно ли factory следующая практика которую вы поставок у вас появилось описание вашей инфраструктуры она может быть довольно базовым то есть это не обязательно все должно быть описана но какое-то базовое описание уже должно появиться для того чтобы могли с этим работать на уши иначе непонятно поверх чего дальше непрерывную поставку общее делать то есть это все практики которые разворачиваются одновременно когда вы приходите где в об суб но как бы начинать нужно с того что понятия что у вас есть и как этим управлять это вот собственно практика только кот дальше вы после того как поняли что у вас есть как этим управлять вы начинаете придумывать как код разработчика максимально быстро отправить на продакшн вы смысле вместе с разработчиками помним про проблему колодцев то есть не отдельные люди это придумывают а вместе мы когда с ваней в ходе курса не отбыл на на на сцене мы увидели первую книжку continues delivery которая вышла в 2009 году джаза хамблах и там группа авторов мы долго думали как и перевести на русский язык и придумали что надо переводить как постоянно доставлять но к сожалению перевели как непрерывная поставку но мне кажется что вот это слово но как-то что-то в нем есть такое русское вот с напором так вот постоянно доставлять это значит что кот всегда может быть выпущен продаж то есть код который вот вас в репозитории как бы продуктовом лежит он всегда может быть в любой момент выключен production он может быть не выкачан но он всегда готов к этому то есть он там стоит и наготове соответственно мы всегда пишете код с чувством некоторого ну она где то вот здесь вот под копчиком вот это чувство я вот часто это когда вот инфраструктурный код выкатывается на у появляется чувство некоторого беспокойства нового у вас должно присутствовать она вызывает некоторые мозговые процессы которые позволяют он писать код немного по-другому соответственно как бы вот это чувство но должно быть зафиксировано каких-то правилах внутри разработки для того чтобы вам постоянно доставлять должен быть и формат артефакта который проходит 1 тур на платформе потому что если вы кидаете по струны платформе разного формата какашки то она у вас появляются не унифицированы она у вас становится не унифицированы и сложно сопровождать проблем технического долго возникает надо летать формат артефакт вам надо выровнять и это собственно тоже задачка коллективно сесть пошуршать мозгами и придумывать этот формат следующая штука за то что артефакт непрерывно улучшается и меняется под production среду во время прохождения по pipeline поставки то есть что это значит это это значит что артефакт он когда двигается по pipeline он все время сталкивается с какими-то неудобными для него штуками которые похожи на то что с чем сталкивается артефакт который вы укладываете production если как бы платить классической разработки он сталкивается обычно под руками системный администратор который вы катку делает то в devops процессе да это происходит постоянно постоянно тут его тестами каким-то какими-то покрутили тут его оберните класть закинули который более-менее похож на право на продакшн тут на него как бы нагрузочное тестирование упустили внезапно это напоминает такое вызвали игрушку pakman да вот вот то есть он какой-то какую-то историю проходит при этом неважно при этом контролировать да как бы реально ли кот историю проходит эта история она как-то связана с вашим продакшеном и история из продакшена можно внутрь conti рус delivery процесса затаскивать то есть вот была у нас когда что-то упало теперь давайте вот этот сценарий просто запрограммируем внутрь внутрь системы и потом каждый раз будет и этот сценарий проходить тоже вы просто как бы с этой проблемой в следующий раз не столкнетесь вы узнаете об этом что он не работает сильно раньше чем он выйдет к вашему клиенту и разные стратегии тепло и огромным 9 в презентации какой-то странный написан ведь я точно помню что писал диплом а вот разные стратегии дипломов это значит что например вы используете оба тестирование либо к новейшей deployment и для того чтобы по-разному щупать код на разных клиентах получать тоже информацию о том как кот работы сильно раньше чем когда это выкатиться там я не знаю на 100 миллионов пользователей вот это собственно что значит постоянно доставлять соответственно как это выглядит да то что вас процесс поставки в этот там д вся и тесты под прот это не отдельное окружение и to stay g по которым у какой станции с несгораемыми сумму которому прорыв проходит ваш ваш артефакт вот соответственно есть у вас есть инфраструктурный какая-то и структурный код который как описан как бы сервис об то он помогает а во первых все сценарии не забыть ее записать тоже виде кода для вот этого вот артефакта а во-вторых тут помогает его продвигать и менять по ходу движения соответственно вопросы для самопроверки время от описания фичи до выкатки production 11 95 процентов случаев меньше недели у вас повышается или качество к артефакты на каждом этапе pipeline то есть если история по которым проходит а и используете ли вы разные стратегии диплом если как бы все ответы дата блин вы ахнете льна и крутая штука вот вся ответа да что же такое ладно давайте я придумал давайте а кого вся ответа нет спасибо спасибо друзья я теперь я ветивер чувствую что вы живы и следующие практика она наиболее сложная на самом деле из всех и вот например тоже я не помню сегодня или завтра коллега из компании инфобиз будет про это рассказывать и о самом деле он будет немного путаться в словах вот потому что это очень сложная практика ему очень тяжело и предлагаю его очень много помучить в в кулуарах потому что как бы ему сложно рассказывать о том что он будет рассказывать про все три практики но при этом для него сейчас важно вот это его сейчас важно именно практика обратной связи он бы ей горит но ему надо будет рассказать про две предыдущие для того чтобы полностью отразить смысл вот этой практике эта практика про то что надо мониторить вообще все то есть например когда то опять таки давным давно когда я работал компании клик мы поняли что нам надо мониторить вообще все мы все это за мониторе у нас что-то там за биг си появилась 150 тысяч атомов который мониторится постоянно у нас это было страшно технический директор кутил немножко у такого риска говорит ребята вы четко и бы сервак то насилуете непонятно чем вот но потом это стало потом случился произошел случай который показал что это реально как бы очень крутая стратегия вот у нас постоянно начал падать там один из сервисов ну то есть вот он не падал и самый главный туда код не дописал потому что такое музыку базовый брокер который как бы там бизнес функциональности почти никакой он просто гоняется общение между отдельными сервисами вот он не менялся 4 месяца и вдруг как бы он стал падать как бы сегменте suv элтон мы такие просто были немного в шоке открыли наши вот эти вот все графики в записи и в общем что выяснилось что оказывается сильно поменялась поведение о поведении запросов этому ну точнее не к этому сервиса сервис который его использует api сервис который за посылают брокер сильно изменилась полторы недели назад мы дальше посмотрели что изменилось изменилось частота посылки определенного типа сообщений вот дальше посмотрели от каких клиентов это изменилось увидишь то это android клиента и дальше мы пошли как бы к android клиентам спросить ребят что томас полторы недели назад случилось они конечно рассказали очень интересную историю о том что они там переделали ю ай ну как вы знаете да что вряд ли они сразу так вот выдадут что они поменяли а что тебе библиотеку ну вот айда них а то я не знаю как как я не знаю мыло сменить вот ванной не просто про это не помнит вот и в итоге упал после там 40 минут разговора мы выяснили что они все-таки сменили тебе библиотеку и а у нее изменились дефолтные тайминги эти дефолтные тайминги привели к тому что изменилось поведение поведение как бы трафика на api сервере и это привело к ситуации которая ну в итоге вызвало гонку внутри брокера и он начал падать штуку которая принципе скрыть есть у вас нет глубокого мониторинга вообще невозможно то есть а если у вас проблемы колодцев еще в организации когда каждый на друг на друга перекидывает это может годами просто жить вы просто как бы restart поставите сервису сервер и все потому что ну невозможно это это разрулить как бы сменить канал и мониторить и все-все отслеживаете как бы трека эти все события которые у вас есть и используете мониторим как тестирование ну то есть вы пишете код и сразу же пишите как его промониторить тоже виде кода мы же уже у нас инфраструктура как кот есть вот сразу пишите как о промониторить вас как бы все становится как на ладони и даже такие сложные проблемы становится легко отследить соответственно как это выглядит на схемке да то что то что надо собирать всю информацию о том что происходит с артефактом на каждой стадии процесс поставки не в продакшене то есть мониторинг надо уже внося его выгрузить и вы там уже увидите какие-то базовые вещи и в тесте увидите при проди увидите на груз на тестирование увидеть то есть как бы вы надо собирать как бы на всех стадиях причем как бы ну не только метрики статистику налоги как выкатилась приложение что при этом было какие кабан аномалии были и ну и так далее то есть надо собирать все если не собираюсь очень сложно разобраться как я вы помните я говорил да devops это про большую сложность то есть с этой сложностью для того чтобы справиться нужно иметь ну как бы нормальную такую аналитику соответствут какие вопросы задать ваш мониторинг логирование то средства разработки для вас то есть как бы ваши разработчики или есть вы сами разработчик вы когда пишете код вы думаете о том как это за мониторить узнаете ли вы о проблемах от ваших клиентов понимаете ли вы клиентом лучший из мониторинга и логирования и понимаете ли вы систему лучше из мониторинга лагерю то есть делаете ли вы изменения просто потому что как бы вы увидели что но вы увидели что например как бы тренд в системе растет и вы понимаете что еще три недели и все загнется и вы меняете при этом систему соответственно когда у вас есть эти три компонента да вы можете подумать о том какая у вас в компании со стороны платформы смыслом суставной платформы то не то что как бы набор разрозненных инструментов до принципе у каждой компании есть набор разрозненных инструментов смысл рф уступка платформы том что все команды пользуются этим инструментом совместно и его развивают совместно понятное дело что отдельных кусков in future на платформе есть отдельные команды которые несут ответственность за развитие этих кусков но при этом ответственность за развитие за работоспособность за продвижение из уст умной по форме несёт каждый инженер по сути дела на внутреннем уровне это становится как и дае для разработчика 1 относиться бережно капусту на платформе надо как как бы я на вы видите дайэн оставить плагин чеки всякие ставите чтоб красивенько было чтобы чтобы быстро можно было там настраиваете какими ходки ими пользоваться и так далее когда у вас вы открываете да мне не знаю sable а им или а там вот у вас visual studio код хорошо я решил просто не мурки тировать вот исчадие ада хотя я тоже пользуюсь решил стать когда вы открываете visual studio код например да и у вас там сыпется как бы ошибка питоны еще что-то и вы понимаете что вообще невозможно работать он сразу становится грустно вы бежите чинить чем у вас плагин произошло вот точно также нужно относиться к вашей основной платформы есть вы понимаете что придет вот не то вы как бы либо оставляете заявку ли вы сами починить не можете если вы сами можете починить там что только бы простое вы сами мы сами чинить и отправляйтесь по request ребятам рассматривают добавляют и так далее то есть это несколько меняется подход в голове к к инженерному инструментарию соответственно что еще делал этом сунной платформы это собственно она в себя запрограммирует набор историй которые с вами случается с вашим кодом в продакшене понятное дело что за много-много лет разработки текстуре становится очень много и много историй которые уникальны относится только к вам вот который мы невозможно нагуглить и в этот момент ваши инфу стоимость платформа становится вашим конкурентным преимуществом потому что в нее зашита то чего не зашита инструмент конкурента и чем более больше как бы глубины у нее есть тем больше вы так сказать тем больше ваши конкурентные преимущества в смысле тенту market и вот здесь собственно появляется проблема winder лак то есть вы можете за использовать чужую культурную платформу при этом вы будете использовать чужой опыт и вы не будете понимать как бы насколько он или wanting вам и это очень сложная грань как бы где понятны делаю что не вся и не всякой компания может построить платформу типа амазона но там есть грань к да где как бы опыт компании он релевантен положение компании на рынке и как бы спускать туда винды лоб нельзя вот об этом тоже как бы важно подумать собственного рода схему появлялась у нас на других сайтах эта схема как бы инфу струнной платформы которая такая базовая который поможет вам наладить все практики и процесс devops компаний то есть у вас есть некоторая система оркестрацию ресурсов которая предоставляет ну циpкa память диск приложениям и другим сервисам поверх этого есть некоторые сервисы низкого уровня до это мониторинг логирование вся сеть engine хранилищ артефактов там инфраструктура как кот система и так далее вот есть сервис высок более высокого уровня это база данных как сервис очереди как сервис лот балансе как сервис а мне зари сайдинг картины как сервис какая-нибудь back to the fabric как сервис ну и так далее и собственно поверх этого у вас есть pipeline который поставляет постоянно модифицированный код вашему клиенту вы получается информацию о том как ваше программное решение работают у клиента поставляя делаете изменения поставляете опять этот код получаете информацию таким образом постоянно развивается инфраструктурную платформу и ваше программное обеспечение но при этом как бы поддержка вот этого delivery pipeline а состоящего из множества стаи джедай здесь для примера показана не надо повторять в ровно в том виде как здесь это принципиальная схема картинка вот взаимодействуют эти стрижи сервисами так сервис то есть каждый кусочек каждый кирпичик платформы он несет какую-то свою историю как выделяются ресурсы как приложение запускается как приложение работает с ресурсами как приложение мониторится как приложение меняется в общем каждый кирпичик несет историю это важно важно это понимать и важно это удерживает что и спрашиваю себя а какую историю несет вот этот вот мой катер печатному как бы можно ли его просто на просто нафиг выбросить и заменить сторонним сервисом например можно ли место кирпичика поставить og метр вот а возможно парни там уже прокачали эту экспертизу гораздо больше чем вы а возможно нет возможно нас есть уникальные экспертизы который как бы метра нет и мы нам надо поставить prometheus и развивать эту дальше соответственно создание платформы это сложный коммуникационный процесс который когда у вас есть базовые практике вы запускаете общение между разными инженерами разными специалистами которые вырабатывают требования стандарта и постоянно изменяя этот стандарт к разным инструментом разным подходом вот здесь вот собственно важна культура которой есть его psy с культурой очень просто это сотрудничестве коммуникации то есть желание работать в общем поле друг с другом желание владеть одним инструмента вместе то есть тут никакого rocket союза все как бы очень просто банально как бы опускаясь там я не знаю то что мы все как бы например живем подъезде и все поддерживаемого частоту вот такой вот уровень культуры соответственно вопрос который вы можете задать до выделили инфраструктурная платформа кто отвечает за развитие инновационной платформу вас компании и понимаете ли вы конкурентные преимущества своим в струнной платформы то есть на эти вопросы надо вообще постоянно себе их задавать отвечать если и можно что-то вынести на сторонний сервис выносить я всесторонне сервис начинает блокировать ваши движения то надо строить систему у себя внутри ну соответственно devops это вот такая вот сложная картинка то есть должен быть цифровой продукт должен быть бизнес модули которые цифровой продукт развивают должны быть команды продуктовая который пишут код практике кантину с delivery платформу как сервис эту янтру стул и как сервис структуру код и отдельные практике поддержания надежности вот ну так devops а зашиваются соответственно по этой картинке тоже можно а еще практика обратной связи которые описывают это все вместе то есть можно идти подкрашивать у всех компаний карпат это у нас уже есть каком-то виде это развилось этой это еще на на развитие так далее соответственно это у меня все предлагаю кармически забросать меня помидорами и я готов ответить на вопросы да кто за дослушать вопросы подаю полотенце добров него из 1 т с этим вот на шейный magic мне очень сильно пора уж ваша ваш рассказ про мониторинг всего и вся и у меня возник такой вопрос тоже такой общий к противный вот для того чтобы 2 с 1 или группа дошли до того что им действительно хватит ну нашлось время или силы чтобы сделать мой турник сегодня продумали это все это на время то ресурсы это вы знаете что у него просто-напросто много свободного времени или наоборот это для него такое давление идет что вы действительно все западала я хочу дело чтоб все будет все было видно как по вашей практике так вам вопрос ну а первых меня ложка строила devops его в группу снова потому что я говорил про всех инженеров компании и все инженеров компании они могут найти для этого времени потому что это реально как бы критично становится а если вы при этом стоите цифровой продукт то есть вы это увидите то увидеть вы увидите как у вас как бы падают и вы видите как у вас появится необходимость микро сервисах потому что это монолитная штука ее как бы клиента рис и дербанят разные стороны и вы начнете как бы сервис выбрасывать вот если бы вопрос ответ на вопрос такой то есть как бы когда у вас появляется цифровой продукт вы не можете не делать на этих вещей то есть не то что у вас время свободные есть просто не можете не делать это становится промочим видно здравствуйте александр ходе своего доклада winner карта упомянули или произнесли ближе обиженная нами для же так так вот так лучше спасибо в ходе своего доклада вы неоднократно повторяли фразу нужно рефакторинг была на этом не был акцент нет ни было центра не знаю почему то я на это обратил внимание скажите пожалуйста так что же все-таки такое dogs я не знаю это все-таки набор практик как об этом говорит википедия или это все-таки методология или это какая-то выделенная роль в команде что это если кратко в 2 предложения википедия нормально определения это набор практик для организации взаимодействия процессов разработки тестирование эксплуатации бизнеса для создания цифрового продукт спасибо большое инженерные практики и ну как бы культуры часть инженерных практик потому что но я не знаю например вытащить сложный токарный сложные детали на токарном станке надо обладать определенной культурой сорян а вот достать у меня такой вопрос выгорели мониторить все и вся вопрос следующий постоянно что-то меняется то есть зависимости от бизнеса за требований клиента и какие-то вещи например происходят какие-то новые мы хотим улучшать некоторые пример проблем возникает и мы потом только а потом постфактум узнаем разбор полетов и делается дополнительно мониторинг вот этой части вот как вот мониторить все и вся опережая если что-то вот на помню свои слова из доклада надо когда вы пишете когда разработчик пишет фичу он должен думать как это промониторить сразу вот если вот и когда выводится тестирование он начинает думать как это протестировать сразу не это и это есть бывало некоторые и как бы такие моменты но мне кажется больше связаны с бизнесом например что-то не отследили но если связаны с бизнесом это значит как бы проникновение продукт оунера в голову разработчика молодых вот и наверное надо этого усилить как и вопрос такой вот вы говорили про не то что долгий диплом а вот именно столкнулись с долго и вот этой скажем не только выкладки оао выкладка выкладка и вот вот ты там месяц занимает вот немножко тут не понятно можно поподробней не совсем понятно о чем можно выполнить тебя и теплеет раз в неделю двумя способами первый способ а у вас разные как бы резные цикла для разных вич и вы их накладывайте слогам в неделю и выполняете это правило вот второй способ это реально как бы от идеи фичи the production в тени недели как бы это один способ курильщика другой способ как бы здорового человека пассию больше вот колегов здрасте спасибо за доклад такой вопрос в основе всего devops а лежит цифровой продукт ну на слайдах это было какие критерии цифрового продукта как определить что это цифровой продукт много про это говорили но понимание этого нет спасибо спасибо за вопрос цифровой продукт он во первых как бы смысл в том что с клиент он взаимодействует программы трасс во вторых при этом происходит оцифровка какой-то части деятельность человека ну то есть например криво поездка на такси поход там вообще как бы готовка еды полностью как бы оцифровывается и ручки из цифрового продукта предоставляются клиенту то есть клиент сам может модифицировать продукт под себя и компания к этому должна быть готова вот компания изучает опыт клиенты пытаются полностью положить внутрь цифрового продукта чтобы ему казалось что это как бы есть часть часть реальности ну как базового так ну можно посмотреть как бы там наир бинбин а uber на бутенко калине предвосхищают наши какие-то желания то есть они это уже увидели кучу людей просто до этого вложили спасибо большое за увлекательное выступление хотелось бы поблагодарить вас еще раз и сделать небольшой подарок от организаторов спасибо большое спасибо