Изменения

В субботу 26.04 был и выступал на 36 конференции [https://sqadays.com '''SQAdays''']. Конференция, как обычно, проходила два дня, но в пятницу я участвовал в [https://dump-ekb.ru/ '''Dump'''], отчет [[Dump-2025]] я уже опубликовал. Поэтому на SQA - SQA — только в субботу. Реально я очень жалею? что не был в пятницу, особенно на afterpaty, где всегда идет активное общение. На Dump это тоже было, но ведь хочется успеть везде. Интересно, что между конференциями есть сильный контраст. Dump - Dump — более молодежно-сленговый, маркером для меня служит вайб для описания хорошей атмосферы, на Dump оно в активном словаре, а на SQA - SQA — не звучит. Это - Это — не единственное отличие, но остальные сложно отчетливо сформулировать, ты просто видишь разницу культур.

Я рассказывал про интеграцию, доклад [[Обеспечиваем устойчивость интеграции (SQAdays-2025)|'''Обеспечиваем устойчивость интеграции''']] - развитие доклада [[Что такое - хорошая интеграция (Saint Highload-2021)]], с фокусом на тестирование. Из вопросов после доклада На конференции я понялвпервые засек, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почемуLLM в некоторых командах перестал быть чем-то забыл при подготовке. Это организационные вопросы обеспечения устойчивости - взаимодействие со смежными командами и заказчикаминовым, создание тестовых стендово чем надо отдельно рассказывать, особенно актуальное а превратился в ситуации, когда "после релизов все разваливается" (это - цитата из вопроса). Это смежные с этим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно. Отдельного рассмотрения требуют вопросы альтернатив рабочий инструмент для распределенных транзакциямопределенного класса задач. Мне очевидно, что распределенные транзакции есть безусловное зло, но надо подробнее показать альтернативы, такие как идемпотентные операции, о которых я говорил недостаточно. А также разобрать современные подходы, такие как SAGA, предполагающая, что реализуется откат - насколько оно реалистично. И подробнее рассмотреть эффекты многопоточной обработки - перестановку порядка транзакций «Мы развернули локальный LLM и псевдопотери. У меня тут точно есть опыт, другой вопрос - получится ли научили разработчиков создавать тестовые наборы данных с его показать с ясными примерами. Будем работатьпомощью» — характерная цитата — маркер такого отношения.

Я рассказывал про интеграцию, доклад [[Обеспечиваем устойчивость интеграции (SQAdays-2025)|'''Обеспечиваем устойчивость интеграции''']] — развитие доклада '''[[Что такое - хорошая интеграция (Saint Highload-2021)]]''', с фокусом на тестирование. Из вопросов после доклада я понял, что тема будет иметь продолжение, потому что есть ряд актуальных вопросов, о которых я почему-то забыл при подготовке. Это организационные вопросы обеспечения устойчивости — взаимодействие со смежными командами и заказчиками, создание тестовых стендов, особенно актуальное в ситуации, когда «после релизов все разваливается» (это — цитата из вопроса). Это смежные с этим вопросы создания mock-объектов, особенно актуальные при отсутствии полноценных интеграционных стендов: технически оно более-менее понятно, но кто несет ответственность, как обеспечить своевременность изменения mock-библиотек при изменениях протоколов. Этих вопросов я немного касался на слайде про тестирование интеграции под нагрузкой, но явно недостаточно. Отдельного рассмотрения требуют вопросы альтернатив для распределенных транзакциям. Мне очевидно, что распределенные транзакции есть безусловное зло, но надо подробнее показать альтернативы, такие как идемпотентные операции, о которых я говорил недостаточно. А также разобрать современные подходы, такие как SAGA, предполагающая, что реализуется откат — насколько оно реалистично. И подробнее рассмотреть эффекты многопоточной обработки — перестановку порядка транзакций и псевдопотери. У меня тут точно есть опыт, другой вопрос — получится ли его показать с ясными примерами. Будем работать. В одном из докладов мое внимание привлекло использование SDLC, Systems Development Lifecycle, которая была вставлена в докладе про Quality Gates в двух вариантах: замкнутая в кольцо и развернутая. Мне схема показалась ребрендингом водопада, я полез смотреть источники и в [https://en.wikipedia.org/wiki/Systems_development_life_cycle вики] обнаружил, что это не ребрендинг, а почти оригинал, доработка водопада в методологии SSADM в 1980-х. Не обнаружив в водопаде Ройса необходимого менеджерам планирования, они приписали его в самом начале, заодно заменив requirements на analysis, ибо не менеджерское дело - дело — над требованиями думать, и выкинув тестирование. Получился процесс для выполнения царских пожеланий "пойди «пойди туда, не знаю куда, принеси то, не знаю что"что». При этом, как и положено столь обобщенной задаче, ИТ-содержание на схеме отсутствует. Практическая иллюстрация к тому, что сон разума рождает чудовищ. Надо будет об этом статью написать, хотя вряд ли это что серьезно изменит. Потому что люди же берут старые схемы, и не особо думают о смысле, который в них заложен, и об их адекватности реальному миру. Отмечу, что в схемах в докладе тестирование сохранено, а планирование и анализ идут параллельно - параллельно — авторы адекватно смотрят на мир. Но я видел схему SDLC не только в этом докладе, и часто это - это — просто проходной слайд, тиражирующий ложную конструкцию.

Дальше - Дальше — мои заметки и конспекты докладов.

Это рассказ о структурировании системы тестов для того, чтобы снизить время тестирования, и при этом увеличить его надежность. Таких докладов много. но в этом интересен объект тестирования - тестирования — аналитический кластер, который собирает данные из разных источников, выполняет по ним расчеты производных показателей по сложным алгоритмам и представляет данные на графиках. При этом полный цикл расчетов занимает около 1.5 часов, поэтому обычный цикл тестирования нашел ошибку - исправил - ошибку — исправил — проверил оказывается слишком долгим.

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

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

Решили изменить подход. И для начала - начала — разобраться в конструкции системы. В презентации была схема, внизу озеро данных, над ним несколько слоев обработки и два выходных плеча: на UI и на другие системы. Плечо на другие системы в тестировании вообще задействовано не было проверяkи проверяли только UI.

На основе структуры получилось сложить тестовую модель. Сделать автоматизированные тестирование на интеграцию, озеро данных - данных — системное плечо. А на UI - UI — смешанное тестирование. Про новую фичу было понятно, где она расположена в модели и как ее тестировать.

Стало много тестов на озеро данных, заливка data-lake покрыта компонентными тестами, которые можно делать сразу, до проектированяи проектирования сценариев обработки. Много автотестов на автоматическую ветку. И это пререквизит на ручное тестирование, приводит систему в нужное состояние. А тесты на UI стали простыми: проверяем, что витрина совпадает с озером, а UI корректно показывает витрину. Используют Artifactory, очень удобно делать слепки - слепки — embeded база данных nitrite.

Легаси из большого непонятного монстра стало понятным и перестало быть легаси. Если система покрыта тестами - тестами — она больше не легаси.

Пришли к разработчикам, чтобы выставить новое API, например, для тестирования сортировки, чтобы не делать его на интерфейсе. Но разработчики не умеют вести тестирование - тестирование — они начали делать чек-листы для разработчиков. А потом развернули LLM и показали разработчикам, как с помощью LLM готовить тестовые примеры - примеры — это взлетело.

За счет автотестов получается сделать ночное тестирование. И хотя оно только ночное, потому что автотестов - автотестов — 16 часов, из них 15 - 15 — расчеты, это дает большое продвижение по сравнению с чисто ручными тестами, которые были раньше.

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

Хороший доклад. Жаль только, что метафору про рожок мороженного не раскрыли... раскрыли…

Четыре истории ошибок руководителей и уроков из них. У меня по ним неожиданная ассоциация: истории очень похожи на истории неудачного построения отношений: в одной паре историй - историй — о том, как партнера (команду) пытаются изменять, а он тебя посылает, а в другой паре - паре — о том, как партнер оказывается крутым, но при этом слабо организованным, что напрягает, и развеивает ореол крутизны. Но уроки при этом о приемах, а не о смене отношения: для первой пары - пары — о том, что надо изменять другими приемами, а для второй - второй — что тщательнее отбирать. А значит истории будут повторятсья, потому что по сути конструкт взаимоотношений не меняется, а именно он является причиной конфликта. Вообще интересно смотреть на истории рабочих отношений с точки зрения создания личных, можно подметить и типовые ошибки и типовые слепые зоны.

Это - Это — общее впечатления. А теперь - теперь — что было в докладе, и послужило основанием. Александр рассказывал первую и третью историю, Диана - Диана — вторую и четвертую, в рассказе я их переставлю, потому что истории Александра - Александра — про реорганизацию команды, а у Дианы - Дианы — про включение нового сотрудника.

'''История-1'''. Трудности с сотрудником. Ему предлагаешь изменения, а он - он — отвергает. Ему дали старую команду, поставили задачу: автоматизация, ИПР, ментора поднанять для автоматизации. И он пошел делать анализ - анализ — как двигаются задачи, посмотрел оценки, поискал ментора. К концу недели составил ИПР, провел демо по улучшению бизнес-процесса - процесса — работа в jira, составил бэклог, позвал эксперта по автотестом, спланировал 1*1.

Последствия. Первый же 1*1 дал отзыв: ИПР - ИПР — ерунда, тест-кейсы у нас свежие, 1.5 года как написаны, все ОК. А вообще, ты - ты — руководитель, давай сначала про зарплату. И нововведения - нововведения — не нужны. Через месяц взаимодействия сотрудник сказал, что выгорел и ушел в отпуск на месяц, а в середине отпуска написал, что уходит.

Что делает по-другому: не составляет ИПР, сотрудник сам; команда сама должна вести технический бэклог - бэклог — она лучше знает; фисирует фиксирует все договоренности; привлек эксперта по области - области — это было правильно.

'''История-3'''. Грабли команды. Приходит эффектвиный менеджер "ребят«ребят, все поменяю" - поменяю» — это он такой. Приходит, видит проблемы, а команда говорит "тут «тут все норм"норм». Хотя он видит: тестовая пирамида не описана, точки контроля не настроена, хранение странное, merge не делают. Он пробует сделать изменения: ведение статусов в jira, сделал встреча три амиго. В результате: путаница со статусами в jira, встречи ради встреч, кофейку попить, а merge стали жать формально. Команда месяц так пожила - пожила — и на ретро была готова порвать его на клочки: постоянные изменения для решгения решения не существующих проблем, мы что, не квалифицированные? Он отошел на месяц, дал команде поуправлять самим. Прошло две недели - недели — ребята провалили релиз. Грабли стукнули довольно больно.

Как теперь:

* новые практики - практики — итеративно, а не все подряд, предлагает последовательность, команда может не принять

То есть финал этой истории в целом позитивный.

'''История-2'''. Была попытка найти сотрудника через ротацию, по пути наименьшего сопротивления. Не удачная, дальше она разгребала последствия. Ситуация: надо было развивать автоматизацию в новом продукте, разворачивать pipeline, чтобы не по кнопке на рабочем месте, а в контейнере. Прежде, чем искать сотрудника снаружи - снаружи — порекомендовали сотрудника из компании, с хорошим опытом. Первые автотесты появились быстро, их включили в pipeline. Но через некоторое время увидела, что среди тестов - тестов — много красных и эта ситуация не меняется. что странно. Пришлось локально развернуть проект, начала смотреть код - код — и появились вопросики к реализации.

А еще все изменения иницциирует инициирует она, инициативы от соутрудника сотрудника не видела. Много 1*1 - 1 — что делаем дальше и так далее. Дофига времени ушло, результата не полчилосьполучилось. В итоге автотесты передали разработчикам, тогда пошел классный фидбек. А сотрудника пришлось снова ротировать. Теперь - Теперь — внимательно смотрит на рекомендации. И смотрит продукт сотрудника на рабочем старом месте - месте — чек-листы, автотесты, и обратную связь на него смотрит. То есть не положиться на чье-то мнение, а решить самой.

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

'''История-4'''. Тоже про нового сотрудника, только не по ротации, а снаружи. И задача та же - же — автоматизация, сделать с нуля и всторить встроить в поток. Нашли звездного сотрудника, инициативного, с богатым опытом. Запустили проект с автотестами, нарастили тестовое покрытие до 8080 %, сотрудник писал статьи в духе звезды, команда была рада. Но! Работа сотрудника не сильно прозрачна. Автотесты - Автотесты — неделями, но результат - результат — непредсказуем: сроки, объем. В коммит - коммит — большие изменения, на 800 файлов.

Вели работу: декомпозировали задач, обсуждали. Не помогало. Работа не прозрачна, тесты не стабильны, нет единого подхода в автоматизации - автоматизации — несколько лидов считали свое мнение правильным, рефакторинг уже 300 часов для масштабирования. Как итог - итог — с сотрудником расстались и передали автотесты разработчикам. История научила стандартизировать какие-то подходы в автоматизации. Описывать инструкции, должен был баланс. Отследиванеи Отслеживание выполнение поставленных задач. И эксперты к ревью проекта.

Итоги. 4 истории. Реально их было больше, их обрезали.

* спрашивайте, почему так полуичилосьполучилось. 5 почему.* оценивайте полученные результаты - результаты — насколько решение разошлось с ожиданиями

Это как раз тот доклад, на котором я увидел SDLC и подумал, что это ребрендинг водопада, я писал в начале отчета. Но сам доклад - доклад — рассказ об опыте quality gate, которые обеспечивают качество. Это - Это — хорошая практика, частный случай таких гейтов - гейтов — всем известные DoR и DoD для конкретных задач, а для больших проектов надо работать с метриками. И в докладе - докладе — очень правильные вещи, например, что если вы допускаете релиз с малым процентом красных тестов, то обязательной частью должен быть позднейший разбор с этим тестами, если их оставлять вечно красными - красными — работать не будет. Хотя, конечно, хотелось бы услышать в этом докладе про больше такой поиск рабочего баланса, потому что это - это — наиболее интересная часть. Ведь отвергают пользу quality gate и подобных практик те. кто на своем опыте сталкивался, как формальное отношение замораживает рельную реальную деятельность. заставляет тратить энергию на преодоление бесполезных препятствий. Поэтмоу пракильный Поэтому правильный баланс, когда гейт поднимает качество, но не останавливает работу - работу — очень важная часть.

Итак, quality gate - gate — это место, где команда проверяет, что все идет нормально. Он включает процессую процессную часть и техническую, обе части могут быть ручными и автоматическими. Процессные гейты контролируют этапы прохождения процесса по договоренностям внутри команды: * планирование и анализ требований, проектирование архитектуры, соотвествие соответствие релизной политике, если она есть и так далее. А технические контролируют метрики инженерных аспетов: code review, покрытие автотестами, проверка на безопасность, написанные тест-кейсы и чек-листы, наличие критических ошибок. Проверка может быть ручная или автоматизированная. там. гед , если ее можно встроить.

* Стартап 20-30 человек - человек — как-нибудь по месту.* Компания с одним продуктом до 100 - 100 — достаточно ручных.* Несколько продуктов 100-500100—500: технические - технические — стабилизированные и автоматизированные, процессные - процессные — в достаточном объеме, можно в jira настроить перевод статусов в зависимости от того, что делают в коде* Корпорация -- Корпорация — нужен безупречный баланс, не облажатьися облажаться и не закопаться. Тут часто встречается, когда делают copy-paste процессов между разными проектами без учета специфики, в результате quality gate работют работают во вред, двигаясь по ним часто теряешь качество.

Я тут хочу отметить, что основная проблема с quality gate как раз в желании сделать все единообразно, игнорируя стадии жизненного цикла преокта проекта и его особенности, и начинается это с 3-4 команд в компании. Перекорсы Перекосы идут в обе стороны - стороны — недостаточные проверки там, где им пора быть и чрезмерные на этапе разворачивания. А в корпорации может принимать уже одиозные формы, как частный случай развития бюрократизации.

Два примера. * Тестовые сценарии, процент прохождения автотестов. НапрмиерНапример, договорились про 80-85. Но: договариваемся, что красные тесты должны быть разобраны, без этого оно не работает.* Управление дефектами. Не только разбираемся с конкретным дефектом и со временем его закрытия, но и смотрим находимость дефекта - дефекта — на какой стадии.

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

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

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

Quality gate не должен замедлять команду (сильно). Если их слишком много - много — попробуй убрать, может они личные. Есть отказные гейты, а есть - есть — где можно пренебречь. Но должна быть договоренность - договоренность — записали в долг и так далее.

Отдельный вопрос - вопрос — про метрики качества. Спросите их у команды, у продукта, у других стейкхолдеров - стейкхолдеров — а потом попробуйте эти представления выравнять. Это - Это — нетривиально.

Сделать все и сразу - сразу — не работает. Фиксируйте договоренности, готовьтесь работать с возражениями, учитывайте уровень зрелости команд. Отсутствие метрик процесса или аудита - аудита — вы не поймете куда двигаетесь. Сделайте дашборд, и не лезьте в сложное. Соблюдайте критерии качества и надежности - надежности — их забывают проговаривать. Это все - все — очень правильные рекомендации, но, к сожалению, без примеров, без приземления на конкретные кейсы. А без примеров такие штуки - штуки — как благие пожелания об активном образе жизни: все согласны, некоторые даже покупают абонемент в фитнес, а вот сколько реально его ведут? Опыт был бы очень интересен.

Agile и гибкость. Очень часто там под этим флагом полностью отвергают любые договоренности. И весь agile ломается. Я тут полностью согласен, и хочу сказать, что agile-манифест писали действующие ИТ-шники, и что помимо ценностей там принципы, где очень много инженерных моентовмоментов. Как раз про работающий продукт. А scrum в этом смысле жесткий: в конце спринта должен быть потенциально поставляемый продукт, который несет (увеличивает) ценность пользователю. Но фокус при этом - этом — на результат, а не на процесс, потому что. к сожалению, процесс не позволяет в ИТ гарантировано достигать результата. Причины, известные много лет назад, описанные Бруксом в Мифическом челвоекочеловеко-месяце и Томом ДеМарко в Человеческом факторе - факторе — по-прежнему актуальны.

Когда пересматривать? Когда что-то идет не так. Все юниты зеленые - зеленые — а оно падает. Смотришь в тесты - тесты — а они вечно зеленые. И осознанный переход на ручной режим, временное снижение критериев - критериев — но ведем техдолг. А еще - еще — инструмент ушел, команда сменилась - сменилась — надо уметь перейти на ручной режим.

Я бы сказал, что когда что-то идет не так - так — уже поздно. Это значит quality gate давно работает во вред: он не обеспечивает качество, и забирает энергию на его обход. Правильно делать регулярный review, и оценивать там достижение целей, которые гейт должен обеспечивать. А еще полезно, если командам разрешены эксперименты. Если чего-то нельзя изменить, то это невозможно и улучшить.

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

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

Сколько стоит работа с опросами? Опросник 30-60 минут, опрос 15-30 мин, анализ 60-90 лидером, дальше встреча 1.5-3 часа всей команды и и 1*1. Если команда из 5 человек, получается около 40 человеко-часов, раз в квартал - квартал — вполне реалистично.

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

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

И так, рассказ на котиках. Что такое виртуальные машины и контейнеры? * Виртуальная машина - машина — это дом для котика со слугами и инфраструктурой* Контейнер - Контейнер — котику для жизни не нужен весь дом, ему нужна коробка с необходимым - необходимым — игрушки, вода и еда, надо чуть-чуть.

* Оркесрация Оркестрация контейнеров* Масштабирование, мониторинг и нагрузка - нагрузка — но с особенностями* Автоматизация развертывания - развертывания — ради этого и берут

* Мастер-нода - нода — там управляющие: ** Контролер-менеджер - менеджер — бабушки на лавочки следят

* Рабочая нода ** Там живут котики в коробках. ** Но! Там же есть помощники от мастер-ноды.

* Нода - Нода — физический или виртуальный сервер, это квартира в доме, где стоят коробочки с котиками. Как и во всякой квартире, площадь и другие ресурсы ограничены.* Кластер - Кластер — подъезд в доме кубернетиса.* Поды - Поды — набор контейнеров, которые запускаются целиком и имеют ограничения по ресурсам, паттерн sidecar. Поды - Поды — логические, они переезжают между нодами.* Сервис - Сервис — имеет списков подов, и знает их в лицо, маршрутизирует трафик на нужный под, знает политики доступа к подам и их адреса. * Реплики - Реплики — запускают несколько экземпляров пода для масштабирования, если одна из реплик умирает - умирает — поднимают другую.

* Контроллер-менеджеры - менеджеры — бабушки на лавочки, которые знают, что должно быть и что есть в моменте, они отслеживают и поддерживают состояние* api сервер - сервер — девопс связывается через него и воздействует.* scheduler - scheduler — размещает поды в кластере. Знает потребности пода и ресурсы нод - нод — и размещает* etcd - etcd — домовая книга key-value, в которую пишут журнал всех изменений

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

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

В конце презентации - презентации — умные книжки, они достаточно известны, и ссылки на статьи с более подробным рассказамИ, котоыре она отобрала.{{wl-publish: 2025-05-01 17:37:31 +0300 | MaksTsepkov }}