Backslashed life

The three dimensional professional projections of spectral light


[sticky post]Сок березовый с мякотью, оптом, самовывоз, гарантия
#000000
cgvictor
(Настало время поменять топовый текст)

Итак, вы пришли в этот ЖЖ. Потому что нашли его по ссылке на меня. Я - это Виктор Ерофеев. Разработчик программных продуктов, владелец бизнеса, предприниматель, инвестор, мотоциклист, фотограф, блогер, инженер, ментор, бывший Microsoft MVP, аналитик, и так далее. Добро пожаловать.

Тем не менее, я - это не мой ЖЖ, который имеет ценность разве что историческую и развлекательную. Если вам хочется со мной пообщаться напрямую, идите в соцсети (например, ВК или ФФ). Если вас интересуют бизнес-коммуникации, то в почту cg@cg.net.ru или в LinkedIn :). В оффлайне ищите меня в Санкт-Петербурге (2/3 времени).

В случае сомнений - в почту.

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

Если вам вдруг показалось, что здесь всегда и всем рады - нет, вы ошиблись, и настаивать на обратном не следует. "Когда хочешь что-нибудь написать – сначала представь, что адресат твоей записи сидит напротив, и в любой момент может выписать тебе по репе, так у всех будет меньше проблем".

So agile
#000000
cgvictor
Я вам такую штуку скажу. Вы только не обижайтесь.

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

Еще раз.

Важно только то, как быстро вы можете их выкинуть и собрать заново.

С минимумом потерь.

recovery: про бабло
#000000
cgvictor
Продолжаем про песцов. Раз уж мы заговорили об облаках, нельзя не упомянуть два самых популярных в 2010+ типа атаки на отказ в обслуживании IT-проекта.
И оба этих типа - "атака на кошелек".

Как раз под новый год сижу с просранным денежным вопросом по двум проектам сразу - грех не написать, тема актуальная ;)

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

Смотрите за руками: бабло уже списалось, а своих прибылей вы еще не факт, что получите. Нагрузку-то вы не просили. Например, дал на вас ссылочку добрый Э.Катчер в твиттере. Или DDOS-атака на соседа вдруг ошиблась адресом. Происходит всё это, конечно же, глубокой ночью. Утром вы просыпаетесь, видите лежащую площадку и -$199 999 на карте, лимит овердрафта. Крутяк? Да не то слово.

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



Не надо думать, что вопрос ограничивается iaas, амазоном-ажуркой. Пример проще: телефония, см слайд выше (линк там умер). Я проверил на 2017, сервер с телефонией начинают пробивать на уязвимости примерно через 45 секунд после развертывания. А еще всегда можно пойти взять пачку симкарт - это ~$0.30/25 рублей за штуку - и дернуть их разом одновременно на ваш корпоративный номер. Сколько у вас внешних транков на АТС? 20? 30? 50? 100? Сотня это мне 2500 рублей затрат. Либо вам предстоит жить без телефона, клиентов и продаж (и без денег); либо вы узнаете, сколько стоит внеплановое увеличение резерва у вашей "облачной телефонии" - оператор будет счастлив взять денег, как получилось на картинке. Т.е опять пустая карта.

Если вы помните, у меня так закончился под нагрузкой фотохост, который 2Q. После ddos-атаки на меня из-за украинских фоточек. Технически никаких проблем, а административно - мне пришлось бы заносить за него в месяц стоимость 1 мотоцикла. А я столько лишнего не зарабатываю. Так что атака достигла цели, пускай не сразу и не туда.


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

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

Или когда даже без санкций "служба безопасности"(тм) крупнейшего мирового регистратора доменов вдруг говорит, что ей не нравится твоя морда (это после 2х лет работы), и ты непременно обязан прямо сейчас выслать им в штаты около 12-ти документов, включая свежие справки из своей налоговой, переведенные и заверенные по форме. А до получения заверенных бумажных копий она, площадка, отключает тебе всё что есть. Понятно, что это у ребят из GD просто на деньги аллергия, и стрелять себе в ногу не запрещено. Но это потом, а сейчас у тебя лежит всё, и типа никто не виноват.

А еще с 2006 года я рекомендую своим клиентам под интернет-проекты брать минимум 2 домена, регистрировать их на разных лиц и держать в склейке. Клюнет петух - расклеите, $10/y не деньги.

Это было про оперативное бабло, короткое. Про "длинное" бабло еще потом будет.

recovery: scale-down
#000000
cgvictor
В 2009м (вроде бы) году душевно общались с Чеппелом в Москве, как раз облака, все дела. Он сетовал на то, что никто основную идею облако-сервисов до сих пор не понял, пока жареный петух не клюнет. А маркетинг всё это положение еще и усугубляет. Потому что продает как основную фичу scale-up. Дескать, вот вы билетный сервис и к вам пришел Coldplay, тонны фанатов смели всю хилую инфраструктуру, а оно рраз!(тм) и заскейлилось, и все работает, знай только бабки заноси.

Вы эту песню слышали.

Так вот, "умное скажу, ты не обижайся". Скейлиться вверх любой дурак сможет, особенно если бизнес-модель адекватная, работает и не продолбана. Когда линия в презенташке идет в правый верхний угол и ща мир захватим. Тут можно и железа закупить, вообще без проблем. И людей нанять. Расширяйся - не хочу. Никаких облаков не надо.

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

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

When life gives you lemons
#000000
cgvictor


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

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

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



Ближе к делу. Камрад kotaff на посленовогодние праздники позвал спбблог, и упомянул, что будем делать и употреблять лимончелло. Разумеется, надо вписываться. И разумеется, пристально посмотрим на рецепт - потому что мой абсент и ром вы, уважаемые читатели, расстреляли со скоростью свиста, а значит надо креатив и настоечки продолжать.



Наше место - Monkey bar. Примечателен тем, что уютный и в центре. Локация Третий кластер, девятая восьмая советская, под арку налево, самый красивый - ваш.

В баре открытая кухня, вроде бы можно туда сунуть морд и наблюдать, как готовят твою еду.



Настоек у нас в рассмотрении пять. Нетерпеливым приведу сразу выжимку по дегустации:

- лимончелло: прекрасен как рассвет, поцелуй средиземоморского солнца и вот это всё
- имбирная с медом: на мой вкус слишком сладко, девочкам понравится. Надо чем-то заедать
- перцовая с розмарином: атомный ад. В смысле ощущений. Я осилил около 30 грамм и попросил пощады. Как образец - идеально, но пить я это согласен только с мороза и под еду. Иначе страшно
- барбариска: барбариска она и есть. У меня с этим вкусом свои ассоциации из бурной юности, поэтому не фанат
- клюква: очень крутая и для меня находка дня. Оказывается, если настаивать не на целых ягодах, то получается всё совсем по-другому. Судя по вкусу, там была еще и брусника. Восторг. Дело вкуса, т.к радость мою разделили не все. Но большинство.

Анна (главная в Monkey по тарелочкам и настоечкам) обещает, что количество настоек будет расти, и дорастет куда-то к двадцати.

Ну а мы пока смотрим на лимончелло. Пока все наслаждаются - тырим рецепт.
Read more...Collapse )

#monkeybarspb
#000000
cgvictor


На фоточке рождается лимончелло. Свежая цедра, лимонный сок, премиальная водка, мед. Просто и со вкусом.

Хоть Новый Год у меня получился трезвым - чему я очень искренне рад - вот уже пятого числа не преминул воспользоваться теплым приглашением Рустама kotaff на презентацию настоек в Monkey Bar. Если коротко - очень крутой теплый и ламповый бар, офигенные настойки (перец суров), отлично посидели и вообще стоит того.

Группа и детали вот https://vk.com/monkeybarspb , сама локация - 9-я Восьмая Советская, 4. Рекламирую нисколько не стесняясь, потому что крутые. Это Третий Кластер, первый этаж, с улицы за аркой налево. Понравилось, если логистика позволит, буду иногда забегать работать. Это, кстати, тоже около Некросадика как был КрайСвета, буквально три дома дальше по улице (где многострадальная булочная). Место хоженое.

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

p.s С перцем аккуратнее, если что.
Tags:

Про опыт и зачем
#000000
cgvictor
Что-то я взялся писать о всякой рекавери и граблезащите. При этом логичный вопрос: "а ты что, по всем граблям прошел?" Нет, не прошел. И не планирую. Чего и вам рекомендую. Вот собственно об этом и разговор.

Безмерно уважаю подход Эдика Хэ в том, что "каждую опасность надо пройти самостоятельно". Но вот увы, в бизнесе и в нормальной разработке у вас это скорее всего не получится. Иногда наоборот, получится, вопреки вашей воле. И тот неловкий момент, когда системный администратор на фразу "надо сделать.." уже только грустно смотрит немигающими глазами. Так не надо делать, это контрпродуктивно.

Всегда должен быть а) копия б) резерв в) инструкция, что со всем этим делать.

И главная здесь, как ни странно, инструкция.

Скорее всего у вас типовых ситуаций не будет. Уже писал об этом: если они совсем типовые, так и говорить не о чем, всё и так понятно. Типовыми будут подходы, направления последующих хаотических метаний и попыток склеить разбитую вазу в сжатые сроки. И вот тут как раз практики работают, потому что там всё довольно предсказуемо. Например, восстанавливать данные вы сначала побежите не в бекапы, а на рабочие машины с копиями. А продолбанные косяки оплаты счетов будете сначала поднимать по бумажкам (если они были). Разговор о том, чтобы они были.

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

2016 completed, 2017 standby check
#000000
cgvictor
Итоги года писать в очередной раз лениво, потому что как переходная дата эти дек/янв уже давно не воспринимаются. Так, душный атавизм и неделя бухаловки всей страной - не более. Однако в качестве ретроспективы 2016 надо бы отметить следующее:

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

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

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

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

- если некоторые человеки ведут себя как долбоебы/хамло/чмо/кидалы и прочими разными нехорошими способами, то гораздо проще сразу признать, что они такие и есть. Априори и целиком. Кому надо, пусть докажет мне обратное; вере в людей есть какие-то пределы и не надо, наверно, на себе их испытывать. Есть занятия интереснее

- в целом год был очень так себе, и совсем не по плану

- буду продолжать пробовать перераспределять занятия и источники дохода

Искренне благодарен тем, кто был рядом со мной в этот год. Реально, вы клёвые.

В 2017 я : наделаю еще больше глупостей ;)
Tags: ,

Recovery
#000000
cgvictor
Вопреки расхожему мнению, аварийный план с отработкой ситуаций A, B, C делается не для того, чтобы в случае их наступления знать, как их решать. RLY. Я слабо могу себе представить реальную потребность в прописанной инструкции восстановления из холодного+горячего бекапов после того, как все заинтересованные люди уже провели их подряд 5 раз, да еще и своей рукой заносили пометки в эти же инструкции. Говорят, обезьяна понимает с третьего раза. Иностранные коллеги - за месяц.

Весь рекавери нужен (действительно нужен) на те случаи, которые во вводных не фигурировали.
Например, когда новая серверная у клиента провалилась на 2 этажа вниз. Двухэтажная. Вместе с потолочным перекрытием между этажами. А старую уже погасили, потому что включили новую - логично же.

И вот тут, когда линейный инженер впадает в праведный ступор, после традиционного "#хуясечёбывает!", внезапно выясняется, что надо всего лишь взять уже подготовленные бекапы и восстановить их на запасной площадке. Примерно так, как делали раньше, с совпадением на 90%. Даже несмотря на то, что новая площадка еще даже дышит, пускай и на первом этаже у входной группы, лежа в виде горки рядом с тем, что ранее было постом охраны. И на все детали и отличия, в общем-то, насрать.

Это примерно как жить в путешествии. Ты не знаешь, куда тебя понесет завтра, но если у тебя палатка лежит справа, рюкзак слева, а остального и вовсе нет, то взять всё необходимое можно за 30 секунд. И никаких внешних зависимостей.


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

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

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

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

А наиболее подлые (для техников) отказы системы - обычно административные и юридические.

p.s В части практической. Поверьте старой обезьяне, разворачиваться на систему-заменитель вам с вероятностью больше 50% придется куда-то на виртуалки. Возможно, на облачные. Потому что железо, сюрприз, само не появится. Разворачиваться придется из скриптов, из контейнеров или из образов (если упомянутые были). Если не было, то из головы наугад, и так не надо.

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

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

Цена рисков
#000000
cgvictor
Ребята в [Ф] задали логичный большой вопрос. Вот ты пишешь про затраты, про саппорт: а почему ты считаешь, что так быть не должно, и все такое - ? Системы ломаются, жизнь меняется, косяки подобного рода были-есть-будут, а ты предлагаешь заранее всё урезать и тупо не сделать ничего.

И да, и нет. Let me show you.



Основным вектором при выкатывании продукта на рынок рано или поздно становится "а давайте реализуем там всё-всё", хотя бы потому что можем. Это продается, массу фич (любой степени сырости) очень любит маркетинг, разработка любит оставить везде места, где можно поднастроить и покрутить отверткой, и - разумеется - давайте впихнем туда все технологии, в-которые мы умеем. Потому что мейнстрим, text big thing и можем.

В чем ущербность такого подхода? Support costs. Тот классический момент, когда к системе постоянно должен быть пристегнут минимум один человек, который получает зарплату и знает, хотя бы как диагностировать возможные проблемы. А возможных проблем там, исходя из уязвимого периметра - тонны. И их тем больше, чем больше гибкости, развесистости, прорывных технологий и прочих свистоперделок.

В советском союзе была хорошая привычка важные и уже настроенные блоки заливать к херам эпоксидной смолой. В них нельзя залезть понастраивать отверткой, их нельзя испортить вмешательством извне, из них нельзя ничего сп*здить, и в случае схода с эксплуатации блок меняется целиком, end of story. Без специалиста, без рекламаций, за конкретные деньги. Понимаете, к чему я клоню?


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

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

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

Предположим, на эксплуатации появилась в системе проблема. Для простоты, положим, чисто программная. Такой средней руки баг, например после неудачного обновления какого-то второстепенного пакета. И исправить его будет стоить нам $100 = это в ценах одеска, 5 чистых часов индусского программиста или 3 часа нормального.

А теперь для простоты расчета напишу вот такую "упрощающую эмпирику", правило какой-то там руки.

Посмотрим, не попадает ли упомянутый баг в следующие категории, даже в несколькие сразу:

1. Проблема срочная - затронутая область имеет временнУю зависимость, с увеличнием времени растут проблемы, значит и реагировать надо срочно;

2. Проблема важная - область относится к критическому/core функционалу, и блокирует часть valued-функций

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

4. Проблема дорогая/денежная/связанная с финансовым блоком. Например, баг в биллинге или сверках. Или связана с выделением доп.финансирования на сдохшее железо из стороннего фонда. Или юридический блокер по финансовым операциям.

5. По возникшей проблеме нет инструкции и/ли регламента для людей

6. По возникшей проблеме нет документации, схемы развертывания, актуальных учетных данных (для техники)

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

8. Проблема имеет затратную часть (самим своим существованием создает прямой убыток, соизмеримый со стоимостью ее решения)

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

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

Если проблема наша попадает в любую из категорий, домножаем стоимость исправления на 2 (200%), а срок исправления - на 1.5 (150%).

Итого имеем: если в нашем гипотетическом интернет-сервисе при обновлении композера из-за чужого говнопакета с гитхаба перестало работать регулярное списание денег с клиентов, на сервис идет платящий трафик, а сделать инструкции на этот счет никто не почесался - мы сходу встряли на [1,2,4,5,8] 100$x2^5 = $3200 (192 000 руб) и на ~22 часа разруливания этого косяка и его основных последствий.

Если в нашей гипотетической системе нечаянно раскатало обновление битого конфига, из-за настройки в котором "всё упало", при этом за devops отвечает сторонний человек, конфиг не документирован (потому что писали его полтора года назад и кто там уже те детали помнит), схема и ключи тоже живут где-то внутри devops-а, система диагностики в конфиг не смотрит; решать надо ессно срочно, подставы такой никто не ждал, и пока всё лежит, мы продолжаем платить running costs в полном объеме - условия правки те же, $100/3h - то считаем [1,2,3,5,6,7,8,10] $100x2^8 = $25600 (1 536 000 руб) и ~76 часов = больше трех суток лежачей и malfuctioning системы, косяков и общей нестабильности.

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

Это те случаи, когда сама системная возможность изменений, гибкость и оставленные дырки для саппорта единовременно выставляют бизнес на деньги. $25k это уже по любому деньги, даже для бизнеса среднего уровня; и вы отдадите их не за новые фичи, вклад сотрудников, развитие софта и т.п, а только за то, чтобы всё работало и сегодня опять стало как вчера.

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

Вишенкой на торте, проблемы с количеством рисковых пунктов 4 и более склонны создавать цепную реакцию - когда административная часть системы тянет за собой юридическую, программная тянет инфраструктурную итд итп. Пример: из-за нарушения обновления в истории 2 слегла железная ферма в неконсистентном состоянии, принято решение переразвернуть из бекапа >> при переразворачивании из бекапа выяснилось, что погасить текущую нельзя (на нее трафик идет), а схема развертывания хз у кого где-то в голове >> помимо уже имеющихся затрат надо теперь искать бабло на вторую копию инфраструктуры, видимо облачную, и перетаскиваться туда со всеми затратами на новый деплой и тесты >> итого, получить одновременно 3 инцидента с оценочной стоимостью в полтора миллиона, и начать неделю с понедельника, -4 500 000 руб затрат и растущим временем на разруливание - тут поневоле задумаешься, а стоило ли оно того.

И зачем эти возможности были оставлены в боевом режиме вообще.

Что делать со списком выше - довольно очевидно, написано много умных книг.
Хотите, могу баек порассказать на тему каждого пункта.

?

Log in