коль пошла такая пьянка, ловите мои:

1. Н-надеждность! ЦОД довольно крупной компании, довольно много серверов на 16-32 процессоров (в доисторические времена одноядерных процов это было огого). мы устанавливаем какую-то мелочь, два сервера по 8 процов каждый. нам строго-настрого запретили даже дышать в сторону "крупняка". все чин-чинарем: стойка, питание слева-справа по карманам, LAN/SAN по оптике. электрикам дали письменное задание провести две независимые линии питания с подключением к выделенным автоматам. перед сдачей проверяем по списку и отправляем электрика выключать одного из автоматов с целью проверки бесперебойности питания. через минуту телефон разрывается и руководитель отдела больших серверов грозит небесными карами, обвиняя, что мы их вырубили. оправдания "ничего не трогали, вон они до сих пор гудят как вылетающий самолет" наотрез не принимаются. угрозы гендиром и финансовые кары на миллионы у.е.

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

2. опять надеждность и дублирование, но уже не аппаратное. крупная госорганизация, принимаю на обслуживание кучу серверов, и среди них выделяются два под управлением БД Oracle Real Application Cluster. оба пашут как сумасшедшие, а в случае обслуживания одного из них нагрузка обоих падает на плечах выжившего. за час до описываемых событии приходит сообщение на почте, что основной остановят для подмены планок памяти. ну и ладно, я же на тот момент работаю на запасном, да и ничего из моих действии никому не должно мешать. все равно во время написания очередной команды текст обрывается на полуслове - я по клаве стучу, а терминал ничего не отображает. быстрая проверка показывает, что все терминалы с тем сервером "капут". звоню мужикам в ЦОД-е: "ребят, вы не тот сервер выключили". получил неожиданный ответ, что они-то выключили правильный и замена памяти идет полным ходом, а по опыту заметили, что в рамках получаса-часа после любых манипуляции по основному, запасной сервер подвисает и его приходится перезагружать. после перезагрузки никаких рецидивов. поэтому они так и сделали, никого не предупреждая, потому что все давно уже привыкли, что после А идет и Б.

разгадка: консультанты из очень уважаемой французской конторы установили архивирование Oracle RAC с изюминкой. по наставлениям производителя два потока транзакции нужно архивировать порознь, а в случае восстановления объединять. особо одаренным тварям пришло в голову объединить их еще во время архивирования, дабы было легче: пространство для архивов на дисках SAN подключить только к первому серверу, не пытаться поднимать Cluster FS ибо муторно и сложно, а устроить из первого сервера обмен файлов второму по NFS. в случае остановки основного сервера услуга NFS есно пропадала, журнал транзакции на запасном переполнялся и БД подзависала. при перезагрузке второго, он поднимал услугу NFS у себя в кластерном режиме, и архивирование прекрасно работало.

3. та же кантора, те же сервера. заметил в журнале, что производитель проводил ремонт каждые две недели и всегда меняли 1-2 планки памяти. управление показывало, что дефективных планок памяти заметно больше. спросил почему весь гемморой с остановом производства два раза в месяц заместо одной подмены всех и навсегда. что мне разжевали на пальцах: серверная рядом в внутренним двориком (мысль: "что??? какое это имеет отношение к делу?"), в дворике площадка и вокруг лавочки (мысли как кони: "мужики, вы издеваетесь?"). какому-то крутому начальнику не понравились стенки/заборчики вокруг площадки высотой в 4-5 кирпича, потому что сидящие на лавочках поднимали на те заборчики ноги, пачкали оные грязью и приходится их белить заново (кто красил траву кисточкой, не смеется). поэтому приказал заборчики поднять до около метра, дабы неудобно было, бреши (то бишь проходы) между стенками тоже замуровать, и все это добро заново побелить. все было прекрасно до первого дождя. заделанные проходы соорудили из бывшей площадки неплохой себе прудик. только о рыбках никто не позаботился, поэтому вода стала искать рыбок сама. искала выхода, искала, пока не нашла его в сторону серверной, как в том анекдоте (Анекдот).

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

ну, а я-то с нашим маленьким и очень дорогим сервером всю неделю показывал меню настроек RS-232 терминала. сервер-то на тот момент в единственном экземпляре во всей стране. представитель производителя сразу заказал новый БП, но предупредил, что выполнение заказа займет 1-2 недели, потом еще растаможивать, тоесть до конца выставки ничего не поделаешь. народ пер, дивился, цокал языком... только один дядька в костюме, в галстуке и с неброскими часами подошел и так вежливо спросил: "ребята, так ведь это меню терминала?" поплакал ему в жилетку, посетовал на электриков, попросил прощения, пригласил его в наш офис где-то недели через три и одарил визиткой. где-то через месяц он все таки отправил своих айтишников нам в гости, с гордостью им все показал-рассказал, кажется даже что-то купили.

p.s. много лет спустя, работая уже на себя, выкупил за мизерную денюжку тот самый сервер и ждет свой час в моем личном музее Плюшкина.

Пожалуй, начну первым, и расскажу пару историй:

1. В одной крупной коммерческой компании, где я на тот момен работал, АХОшникам потребовалось проверить пожарную сигнализацию. А тут стоит сделать отступление, сигнализация была газовая.

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

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

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

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

Начал разбираться в причинах  и выяснилось, что по распоряжению работавшго на тот момент в компании архитектора, в серверном и менеджмент сегменте сети [Хотя сегментов по сути не было, все торчало голой жопой в общую сеть, без какого-либо  ограничения доступа] использовался DHCP, что является грубейшим нарушением Best Practiсes. Но и это было еще не всё. DHCP сервер был один, на физическом сервере, причем гипервизоре. В мониторинге его не было. DHCP не был развернут в HA-режиме, бэкапов не было. Да и в документации тоже ничего про него не было сказано.

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

И не только с документацией.

В один прекрасный день просто истекла аренда, и 200+ ВМ потеряло сеть. Единственное, что повезло с менеджмент-интерфейсами, аренда которых еще не истекла. Решение проблемы обошлось мне в бессонную ночь.

3. Компания, где я на тот момент работал, только что переехала в новое, построенное специально для нее здание. Вместе с ней прошел переезд с кучи старых сервисов, на их новые версии, например, с Novel Netware на Windows Server 2012 R2. Это в принципе отдельная песня, но ее я затрагивать не буду.

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

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

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

И вот тут то начинается самая мякотка. Я, договорившись с руководством, свалил на вендорское мероприятие. Пока я отсутствовал - пришел подрядчик, и это самое руководство допустило его в серверную. Кабель из щитка он протянул. А вот что был дальше, история умалчивает.

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

Приехав, я вижу картину развалившегося Hyper-V кластера. Причина развала - оказалась в том, что SAN-свитчи Brocade, равно как и коммутаторы Catalyst, наглухо повисли. Дальше - мои предположения, разве что. Видимо, при подключении кабеля, сотрудник подрядчика случайно устроил КЗ с корпусом стоек, и коммутаторы решили в таких условиях не работать, и дружно повисли.

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

В общем, обошлоь все малой кровью, но сама история запомнилась.

А у вас есть что рассказать?