Был задан вопрос на интервью админа

Если у вас такое «внезапно выяснилось» - вы уже провалились как профессионал.

И это вопрос не CI, а CD.

Туши обновленную часть приложений, разбирай кластер БД (кстати, какого рода кластер-то, и какое изменение схемы имеет место быть?), запускайся на необновленной части.

вопрос уровня «rm-rf снес половину файлов, и тут вы поняли что зря»

поддержу @subwoofer
@Den0k также хотелось бы получить в конце ваше решение

какого рода CI вы бы хотели иметь

я бы хотел иметь QA, QC, чтобы такого рода вещи отлавливались на Testing\Stage этапе.

Правильный ответ - «валить нахрен из такой команды»

тоже склонен поддержать @subwoofer но такой вопрос был задан, причём компетентность того кто «внезапно обнаружил» не была включена в него, то есть за рамками. Просто так «дано». Какой там кластер не уточнялось.

@leave А почему вы считатете что это больше CD?

Я бы не сказал что я выдал решение, скорее ответ, кратко он был что-то вроде - факап неизбежен, он уже случился часть инстансов уже выдаёт ошибки ющерам и хорошо бы что не 500 Internal server error, а что-то более дружелюбное. А так я бы хотел иметь в своём распоряжении любой инструмент (вот, кстати, тут, подскажите может какой?...) который бы позволил автоматически накатывать апдейты, а также ревертить на прошлую версию, так образом он бы мне позволил отметить группу инстансов которые надо откатить и применить откат. Ну и конечно, раз апдейт отменён схему вернуть как было.

(зачем тут кто-то предложил разбирать кластер БД?, скорее всего там синзронная репликация и всё уже заккомитилось.)

Туши обновленную часть приложений

т.к. ТС наводящих вопросов не задавал, возможно что-то некритичное. чего сразу тушить то?
можно подеградировать часок.

(зачем тут кто-то предложил разбирать кластер БД?, скорее всего там синзронная репликация и всё уже заккомитилось.)

если репликация то оно уже на 100%, что не соотв. условию задачи

почему не соответсвует?

а исходном вопросе, обновилась часть инстансов (код) приложений, а база обновилась полностью.

он уже применён на 50% инстансов приложений и к базу

Так это надо понимать как бд обновидась целиком?

да, надо читать «и в базу» / «и к базе»

опечатка, прошу прощения :)

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

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

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

Только вот при чём тут CI? Ну да я не админ, мож чего не знаю

Сделать на сервере rm -rf /

Хуже точно не будет.

А потом восстанавливаться из бекапа, он то хоть есть?

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

Только вот при чём тут CI? Ну да я не админ, мож чего не знаю

Вопрос был «какого рода CI?» — я бы предпочел иметь CI, которое выкатит бэкап последней рабочей конфигурации, т.е. то, что было до обновления, т.к. целостность системы уже нарушена, хз как что обновлялось и сходу придуманными заплатками лечить ВНЕЗАПНО появившиеся проблемы не стоит.

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

Это не внезапно должно быть. А вместе со скриптом обновления положить скрипт отката.

Хэштеги забыл :)

наименее безболезненно

Собеседовался админом в садомазо-клуб? А зачем им база?

У нас в конторе примерно такой сценарий «многоопытные админы» используют для обоснования почему нам нужно уметь делать релиз за пять минут.

То есть ответ на вопрос был бы - «быстрый». Мол если всё остальное не остановило проблему на подступах, то главное - это скорость деплоя пофикшенной версии (это может быть предыдущая версия, может быть новая, не важно).

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

Типа «если вы хотели спросить про то - то вот так и так, а если про это, то по другому..»

как вы думаете как бы ответил продвинутый devops админ

А почему я как devops вообще должен в этим заниматься?
Моя задача как devops разъяснять программистам и пользователям позиции друг друга.

пользователи-то тут причем

Тут как раз все четко, ops кричат «всё упало!!!», dev отвечают - «умвр!!!», а ты как devops бегаешь между ними и пытаешься понять кого же из них надо пнуть, чтобы починилось.

Тут как раз все четко, ops кричат «всё упало!!!», dev отвечают - «умвр!!!»

А Project manager из аутсорсинговой компании, где они все работают, набирает в скайпе: Привет! Как дела? Всё уже работает? Не забывайте, что сдавать надо в 9 утра по MSK.

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

Как получилось так, что такой факап прошёл в продакшн? Какова ситуация с бэкапами?

какого рода CI вы бы хотели иметь в своём распоряжении чтобы наименее безболезненно справиться с ситуацией?

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

От жизни отстал ты. Нынче девопсами зовут школоту со «знанием питона» и видившим когда-то дженкинс на картинках.

Если есть человек-девопс, который обязан кому-то что-то объяснять - значит всё очень, очень плохо

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

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

Проблема в том, что это работает, когда ты Google.

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

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

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

были другие, хуже)

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

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

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

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

а вот в «средний класс» лучше не ввязываться: там будет супер-конкуренция между разработчиками с низким уровнем входа в тему, и организациями которые из них состоят. Заниматься чем-то легким на самом деле куда труднее, чем сложным))

иначе говоря, лучше быть богатым и здоровым, чем бедным и больным :)

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

Бекап? Думаю, от тебя хотели банально услышать что-то про Chef, Puppet, Ansible, Docker.

приклады раскатываются как новые инстансы, на которые балансером плавно перемещается нагрузка со старых нод. Откат тривиален.

Базы защищаются при помощи https://dev.mysql.com/doc/refman/5.6/en/replication-delayed.html, тогда не теряется время на разворачивание бэкапа. Система должна позволить накатить все операции повторно за время delay.

мне нравится концепция гугла и майкрософта

МС и Гугл - это очень жирные и крайне неэффективные корпорации. Перенимать их опыт можно только в том случае, если у твоей кампании столько денег на счетах, что можно хоть хоровым пением на работе подчиненных дрючить - ничего не изменится, лишь бы люди зае##лись, а то не красиво как-то им деньги за сидение на ж# платить. Как так нет моего и твоего кода ? Ты бредишь, дядя ? Я пойду чужой код править штоле или кто-то пойдет править мой ? Как ты вообще представляешь разрешение ситуации в случае факапа ? И кого вообще наказывать ? Фсех, да ? Ну-ну.

И кого вообще наказывать ? Фсех, да ?

ленин, уже 100 лет как не 17й год. кого ты собрался наказывать?
man blameless

очень жирные и крайне неэффективные корпорации

в командах из 3 человек как раз общее владение кодом почти всегда. Не имеет смысла разводить бюрократию, фигак-фигак и в продакшен

Гугл привожу в пример потому, что вот как раз для жирной корпорации - это великое достижение. Жирная, но эффективная.

Я пойду чужой код править штоле или кто-то пойдет править мой ? Как ты вообще представляешь разрешение ситуации в случае факапа ?

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

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

Ну, объясните, мне, дебилушке, как этот ваш блеймлесс на практике выглядит. Вот я накосячил. Вот всё встало из-за меня колом. Что дальше ? Я сижу такой улыбчивый и пейшу отчет о проделанном тяжелом труде, рассчитывая на премию, и напевая корпоративный гимн.

Товарищ, если кто-то правит твой код, значит, ты - не нужен. Задача должна быть четко разделена на части и зоны ответственности. Там где коллективная ответственность, там и коллективная безответственность. Это полная чушь то, что ты пишешь.

лучше, чтобы служба безопасности проводила тебя в подвал, откуда ты, через пару дней, не своим ходом отправишься в GULAG?
ты лучше расскажи, что значит «наказывать»? psychological abuse?

внезапно

Сейчас это стало модным трендом в планировании?

Лучше чего ? Вы так и не объяснили, как выйти из факапа с помощью этих ваших блеймлессов и «нет моего и твоего и кода». Вот я сижу и улыбаюсь. Из-меня теряется допустим миллион в сутки. А я сижу и улыбаюсь. А што мне плакать, штоле. Моего кода тут нет, наезжать на меня не смей. Блеймлесс, ч0.

и чего? да хоть трильярды в сутки, от того, что с тобой что-то сделают или как-то будут взаимодействовать исходя из суммы — что изменится?

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

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

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

Да вопрос не в том, как меня четвертовать, депремировать, или просто пожурить на первый раз. Как проблему решать вообще. Факап решать надо ? Как ?

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

У нас проблема такая же с оутсорсом была.
Ребята что-то там делали, проверяли. Мы внедряем, контролируем, делаем замечания по устранению и т.д. Всё хорошо, пока конракт не закончился.
Потом либо самим как-то заниматься эти, либо новый контракт писать.
В итоге сейчас 50/50 работ между оутсорсом и фирменными программистами. (программирование не наш профиль, просто зазказчику так надо).
И решение проблем, в итоге, лежит на нас, а не на оутсорсе. Мы может дрюкнуть оутсорс, но только пока они на контракте, а потом всё равно самим разруливать.
Короче, вся история свалилась в хатоскрайность, т.е. это мой код - я его знаю, что там Вася Колупайник наделал - пусть он и делает, потому, что взять на себя фронт - значит подписаться за головняк, «потому что можешь». Профитов нет тут от геройства никакого.
Классическое - инициатива дрюкен ин попен инициатора.
Так что блеймлессовцы быстро рассосались, когда пришло время расставить точки над И.

Факап решать надо ? Как ?

какой факап? ну случилось что-то, где-то не работает «внезапно», как в примере ОП или хуже.
если причастные будут марозится по углам, выяснение причин может занять больше времени, чем решение проблемы.
вся суть этих агилов, блеймесов и боление за продукт придуманы и рекламируются не для отдельного человека.
дело в процессах, никому не интересно, что ты считаешь своей зоной ответственности, или даже куски кода наделяешь свойством «мой»
отдельной личности вообще выгодно с точки зрения калорий и гармонов ничё не делать.
если ты принимаешь это как глупости (культ карго) — тебе не интересен процесс, ты невыгоден.
если HR не вовлечёт — машину времени в 70-е в ibm waterfall