Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Сдох контроллер
Заказчик М…
Конец истории
Таких историй и таких заказчиков, миллион, к сожалению
Заказчик М…
Конец истории
Таких историй и таких заказчиков, миллион, к сожалению
Цапля чахла, цапля сохла, цапля сдохла
напомнило проблемы «Cloud for Box»
Что за СХД такая, что (а) не выдаёт алерт с рабочего контроллера, когда синхронизация с новым не состоялась; (б) не хранит конфигурацию на самом дисковом массиве, чтобы контроллеры могли её прочитать.
Страна должна знать своих героев!
Похоже на HPE
Huawei, думаю, можно исключить: у них для этих целей есть coffer disk. Цитата: «Coffer disks are used to store three types of data: cache data requiring power failure protection, OceanStor OS system data, and system configuration information and logs.»
p.s. Если это не совсем то, прошу извинить — с СХД только-только начал вплотную знакомиться.
p.s. Если это не совсем то, прошу извинить — с СХД только-только начал вплотную знакомиться.
Как минимум у 3PAR есть VVOL «admin», не считая дисков в самих контроллерах, в EVA системные данные есть в Default Disk Group. Если что-то из серии программно-определяемых СХД, то при чём бы тут «контроллер». Жаль, что автор в одном из комментариев ниже отказался сообщать модель СХД. Ведь и у хороших производителей случаются удачные и неудачные модели, соответственно, относительная неудачность (скорее, неудачная индикация «зелёной лампочкой» при наличии Alert) одной модели — не повод отказаться от СХД этих производителей.
Дальше второго этапа не осилил. Выгнать н… й такого идиота и системного администратора заодно. На вопрос "За что?" — читайте документацию и выполняйте свою работу за которую Вам платят зарплату. Не нравится — валите. Вот поступок настоящего руководителя. Развели сборище недоинженеров. Позор тому человеку, который допустил данную ситуацию.
Не совсем понятно, почему новый контроллер не подтянул настройки со второго, работающего. Это что за отличное такое резервирование, что мало того, что ничего не пишет про пустой контроллер, так и не вводит его в рабочее состояние? Можно подробности про СХД, чтобы никогда ее не купить.
Еще вопрос — а почему не проверили работоспособность нового контроллера?
Еще один есть — а при получении первого Alert-а, не отправили его содержимое профи? Я о том, профи знал, что внутри алерта написано — у вас умер контроллер?
Еще вопрос — а почему не проверили работоспособность нового контроллера?
Еще один есть — а при получении первого Alert-а, не отправили его содержимое профи? Я о том, профи знал, что внутри алерта написано — у вас умер контроллер?
Настройки не подтянулись автоматически — конструктивная особенность модели, т.к. в инструкции к смене контроллера нужно «ручное» участие администратора (даже одну-две кнопки нажать в GUIвсе равно участие, как впрочем и одна команда в CLI).
«Ничего не пишет» — СХД как раз писала. Но слова профи: он вынул, он вставил, загорелась зеленая лампочка… Т.е. «профи» решил что все ОК, когда погас индикатор ошибки и загорелась зеленая лампочка… Обращать внимание на Алерты «не его дело», а смотреть логи вообще «нонсенс». Последнее предложение — сарказм. А что делал админ? Новый админ видимо пришел после этого, а старый уже ушел. Т.к. во время ЧП профи говорил про себя, что он вынул, вставил и лампочка загорелась.
Подробнее про СХД, чтобы не купить — история пятилетней давности, эта модель больше трёх лет снята с производства, т.е. её уже не купишь. хотя теплоты к этому вендору у нас никакой, так жестоко поливать совсем неэтично, опять таки 5 лет прошло.
Почему не проверили работоспособность контроллера, не знаю. Нас не допускали на площадку, " Мы и сами справимся". Настоять же — нет оснований.
Про нас могу сказать, что мы доходчиво донесли информацию о проблемах и возможных последствиях, как только получили логи с СХД для помощи в открытии тикета.
То, что контроллер умер у профи, он видимо осознал только когда были сняты логи, иначе нам просто не понять такое отношение. Полученные же Алерты его администратор заводил в местный аналог «service desk», где профи кстати и отвечал. Со слов администратора из второго дня могу сказать, что профи должен был их видеть, как минимум до тех пор, пока админу не сказали: работает, не трогай. Далее не знаю, сам профи не делился подобной информацией. А как профи читал алерты, если читал, тем более не знаю, но результаты довольно красноречивые: сообщения СХД игнорировались.
«Ничего не пишет» — СХД как раз писала. Но слова профи: он вынул, он вставил, загорелась зеленая лампочка… Т.е. «профи» решил что все ОК, когда погас индикатор ошибки и загорелась зеленая лампочка… Обращать внимание на Алерты «не его дело», а смотреть логи вообще «нонсенс». Последнее предложение — сарказм. А что делал админ? Новый админ видимо пришел после этого, а старый уже ушел. Т.к. во время ЧП профи говорил про себя, что он вынул, вставил и лампочка загорелась.
Подробнее про СХД, чтобы не купить — история пятилетней давности, эта модель больше трёх лет снята с производства, т.е. её уже не купишь. хотя теплоты к этому вендору у нас никакой, так жестоко поливать совсем неэтично, опять таки 5 лет прошло.
Почему не проверили работоспособность контроллера, не знаю. Нас не допускали на площадку, " Мы и сами справимся". Настоять же — нет оснований.
Про нас могу сказать, что мы доходчиво донесли информацию о проблемах и возможных последствиях, как только получили логи с СХД для помощи в открытии тикета.
То, что контроллер умер у профи, он видимо осознал только когда были сняты логи, иначе нам просто не понять такое отношение. Полученные же Алерты его администратор заводил в местный аналог «service desk», где профи кстати и отвечал. Со слов администратора из второго дня могу сказать, что профи должен был их видеть, как минимум до тех пор, пока админу не сказали: работает, не трогай. Далее не знаю, сам профи не делился подобной информацией. А как профи читал алерты, если читал, тем более не знаю, но результаты довольно красноречивые: сообщения СХД игнорировались.
История слегка похожа на выдуманную.
И не пойму зачем выдуманную, ладно бы идею дельную выдуманная история показывала.
Может не осознал я чего. Но меня после прочтения бомбануло, т.к. с темой СХД и алертов чуть знаком.
Но извиняйте, гугль выдал в рекомендацию заинтересовавший заголовок, прочитал и меня бомбануло, поэтому многобукв:
1. И СХД какая-то сомнительная, как тут уже ответили.
Которой не достаточно, чтобы контроллер поменяли и сама прочитать настройки не умеет.
И которая при фактически неработающем втором контроллере алерт гасит.
И что при умершем контроллере только через пару месяцев кто-то что-то заметил.
И придумать, что такое «контроллер сбоит, но ошибки исправляет на лету» вот сходу не могу.
Ежели это не ECC ошибки памяти или не SCSI ошибки по шине.
Но это значит, что он (или его компонент) приговорён и таймер запущен.
И зачем СХД выключать (на это делается акцент: что меняли не выключая, что зачем-то нужно менять, чтобы заменить второй).
Да и по факту, если уж действительно СХД такая нежная, что надо на контроллер настройки восстанавливать (откуда?) отдельной процедурой, то если один контроллер в боевой режим не завели (не всосал настройки ip и например карту мапинга томов и рейдов на диски или ещё чего (наверное это понимается под «пустым новым»), а второй умер…
То восстановление тут скорее всего мягко говоря нетривиальным будет — т.к. имеем два «пустых» контроллера и либо им достаточно только ip-шники дать. Ну или просто вывести контроллер из какого-нибудь «режима обслуживания».
Короче либо вся техническая соль тут опущена, либо…
Про СХД, которая получает ip адреса (управления или доступа к данным?) по DHCP, который лежит на ней же — тоже история сомнительная. Как аллегорическая иллюстрация идиотизма — да, как в жизни — очень сомнительно (это надо с одной стороны заморочиться сильнее, чем чтобы выдать статику, с другой — не думать головой совсем).
2. Непонятен статус помогающих: вроде попросили их всё-таки помочь, рассказчик говорит о том, какие они крутые во всём: и диагноз поставили, и с кейсом помогли, и серийник запротоколировали, и контроллеры прямо с таможни заместо вендора получали (чёй-то?). Да и вендор то какой-то, у которого контроллеров «как водится» нет на складе.
Но в итоге то не помогли, не сумели, позволили факапу случиться.
Сумели похвастаться.
Непонятен и статус конкретного помогающего (литературного героя): кто он — инженер, что гайки и СХД крутит и на память все настройки помнит? пресейл? менеджер? Человек-оркестр?
А то про «бесплатную работу» и «спасибо не буркнули» — вызывает вопросы. Ежели инженер — зачем впрягался? (и зачем по телефону за спасибо ДЦ 24х7 поднимал? а ежели бы на тот конце провода не туда жамкнули — и данным всё — кто бы отвечал?). Ежели менеджер — почему инженер работал за бесплатно? Если пресейл — ну тогда нужно грамотнее байки на habr сочинять =)
Но вот было бы правдой, врядли стали бы писать историю на habr, где можно угадать заказчика. И где откровенно поливаете и называете глубоко некомпетентным их технического директора.
Если правда с ним регулярно работаете.
Или там и habr никто не читает.
Да и всё-таки не верю:
Ни про «пару минут безответного стука» чтобы понять, что вся инфраструктура лежит (а не сетевушка в ноуте или порт коммутатора неисправны).
Ни про то, что на восстановление суммарно ушло «четыре десятка минут».
И что решено это было всё не по удалёнке, а по телефону.
контрастирует такая скорость с тотальной некомпетентностью сотрудников на месте.
Так как представляю реальные тайминги решения проблем и статистику имею не один год. Особенно если в это время профи искал базовые сетевые настройки СХД, а не взяли их например из диагностики, которой помогали при открытии кейса, ага.
Ну и если бы правда мы имели бы СХД вот с двумя голыми контроллерами (без конфигов) и продуктивными данными внутри. Это работа где ошибаться не стоит — в общем случае легко можно сделать так, что данных больше не будет (решит контроллер диски переинициализировать например, не то нажмут на том конце провода). Не делают такого вслепую по телефону, имея на том конце провода того, кто не осилил контроллер корректно заменить.
Хотя ладно, это просто моя зависть, придётся поверить и смириться, что есть спецы покруче и отважнее меня на порядок.
3. Мораль или польза истории непонятна. История по сути про тотальную некомпетентность по кругу.
Про некомпетентность технического руководителя заказчика.
Про некомпетентность того, кто контроллер менял (или это руководитель и был?)
Кто не смотрел в управлялку СХД.
Кто не смотрел в управлялки среды виртуализации (чай там не всё в порядке с путями было).
Кто кейс в поддержке у вендора закрывает без подтверждения по диагностике, что с СХД всё ок.
Вендора, у которого регулярно контроллеров на замену нет.
И сомнительный героизм лирического героя.
А рецептом предлагается ввести некоторую бюрократию и ответственность.
Что в целом то хорошо и инновацией не является.
Но кто ответственно и вдумчиво составит такие планы?
Сотрудники, некомпетентность которых продемонстрирована?
Или консалтинг, что всё проанализирует, денег возьмёт, означенные талмуды схемы и картинки нарисует?
Инструментарий ведения и поддержания в актуальном виде не предлагается. Excel?
Или брошюрованные талмуды в сейфе под роспись?
Вот про хороший и удобный инструментарий для не самой большой в мире компании было бы интересно.
А уж ежели даже про инструментарий. Коли рассказали подробно про категории алертов — то можно было бы например сказать, что во многих системах алертов: в том числе и на некоторых (не всех) СХД, и не только, есть часто такие функции как:
— aknowledge -подтвердить, что сообщение кто-то видел
— resolve — снять алерт, если система сама не сняла по устранению проблемы
Ну и комментарий во многих можно оставить (почти как комментарий к тому, почему Win собираетесь перезагрузить).
Да и что заходить в управлялку желательно под индивидуальной (доменной например) учёткой.
И чтобы правилом было, что алертов или warning неразрешённых висеть не должно.
И в результате не быть алерта, про который все знают, что есть, но никак не дойдут руки снять (а новый потом не заметят).
Т.е. сами эти алерты отчасти задачу планов решают.
Не говоря уже про системы мониторинга, CMDB и прочая по пути к светлому ITIL.
А если админ говорит, что боссу доложил и задачу выполнил, а реакции два месяца нет — планы не помогут.
А рецепт чтобы было всё нормально с СХД.
1) Компетентные сотрудники.
2) Нормальные СХД.
3) Нормальная поддержка и настройка отправки алертов тому, кто в них понимает.
Над примером планов, где «Потеря данных (продуктивных)» это средняя вероятность нарушения работы.
И которое индицируется «Всплывающим уведомлением».
И решается «Автоматическим восстановлением»…
поржал и призадумался. С этим то другой вопрос связан, на который ответа для себя толком за многие годы не нашёл за долгое время общения с СХД.
Бомбануло и поржал, поржал и бомбануло.
История выдуманная, много нестыковок, зачем написано — непонятно.
Единственный вывод — если в некомпетентные сотрудники, а тем более в руководстве — будет печально.
А лирический герой — д'Артаньян.
И при этом зачем-то про какие-то планы, какие-то СХД, какие-то алерты, которые лишь антураж для этой сюжетной линии.
И не пойму зачем выдуманную, ладно бы идею дельную выдуманная история показывала.
Может не осознал я чего. Но меня после прочтения бомбануло, т.к. с темой СХД и алертов чуть знаком.
Но извиняйте, гугль выдал в рекомендацию заинтересовавший заголовок, прочитал и меня бомбануло, поэтому многобукв:
1. И СХД какая-то сомнительная, как тут уже ответили.
Которой не достаточно, чтобы контроллер поменяли и сама прочитать настройки не умеет.
И которая при фактически неработающем втором контроллере алерт гасит.
И что при умершем контроллере только через пару месяцев кто-то что-то заметил.
И придумать, что такое «контроллер сбоит, но ошибки исправляет на лету» вот сходу не могу.
Ежели это не ECC ошибки памяти или не SCSI ошибки по шине.
Но это значит, что он (или его компонент) приговорён и таймер запущен.
И зачем СХД выключать (на это делается акцент: что меняли не выключая, что зачем-то нужно менять, чтобы заменить второй).
Да и по факту, если уж действительно СХД такая нежная, что надо на контроллер настройки восстанавливать (откуда?) отдельной процедурой, то если один контроллер в боевой режим не завели (не всосал настройки ip и например карту мапинга томов и рейдов на диски или ещё чего (наверное это понимается под «пустым новым»), а второй умер…
То восстановление тут скорее всего мягко говоря нетривиальным будет — т.к. имеем два «пустых» контроллера и либо им достаточно только ip-шники дать. Ну или просто вывести контроллер из какого-нибудь «режима обслуживания».
Короче либо вся техническая соль тут опущена, либо…
Про СХД, которая получает ip адреса (управления или доступа к данным?) по DHCP, который лежит на ней же — тоже история сомнительная. Как аллегорическая иллюстрация идиотизма — да, как в жизни — очень сомнительно (это надо с одной стороны заморочиться сильнее, чем чтобы выдать статику, с другой — не думать головой совсем).
2. Непонятен статус помогающих: вроде попросили их всё-таки помочь, рассказчик говорит о том, какие они крутые во всём: и диагноз поставили, и с кейсом помогли, и серийник запротоколировали, и контроллеры прямо с таможни заместо вендора получали (чёй-то?). Да и вендор то какой-то, у которого контроллеров «как водится» нет на складе.
Но в итоге то не помогли, не сумели, позволили факапу случиться.
Сумели похвастаться.
Непонятен и статус конкретного помогающего (литературного героя): кто он — инженер, что гайки и СХД крутит и на память все настройки помнит? пресейл? менеджер? Человек-оркестр?
А то про «бесплатную работу» и «спасибо не буркнули» — вызывает вопросы. Ежели инженер — зачем впрягался? (и зачем по телефону за спасибо ДЦ 24х7 поднимал? а ежели бы на тот конце провода не туда жамкнули — и данным всё — кто бы отвечал?). Ежели менеджер — почему инженер работал за бесплатно? Если пресейл — ну тогда нужно грамотнее байки на habr сочинять =)
Но вот было бы правдой, врядли стали бы писать историю на habr, где можно угадать заказчика. И где откровенно поливаете и называете глубоко некомпетентным их технического директора.
Если правда с ним регулярно работаете.
Или там и habr никто не читает.
Да и всё-таки не верю:
Ни про «пару минут безответного стука» чтобы понять, что вся инфраструктура лежит (а не сетевушка в ноуте или порт коммутатора неисправны).
Ни про то, что на восстановление суммарно ушло «четыре десятка минут».
И что решено это было всё не по удалёнке, а по телефону.
контрастирует такая скорость с тотальной некомпетентностью сотрудников на месте.
Так как представляю реальные тайминги решения проблем и статистику имею не один год. Особенно если в это время профи искал базовые сетевые настройки СХД, а не взяли их например из диагностики, которой помогали при открытии кейса, ага.
Ну и если бы правда мы имели бы СХД вот с двумя голыми контроллерами (без конфигов) и продуктивными данными внутри. Это работа где ошибаться не стоит — в общем случае легко можно сделать так, что данных больше не будет (решит контроллер диски переинициализировать например, не то нажмут на том конце провода). Не делают такого вслепую по телефону, имея на том конце провода того, кто не осилил контроллер корректно заменить.
Хотя ладно, это просто моя зависть, придётся поверить и смириться, что есть спецы покруче и отважнее меня на порядок.
3. Мораль или польза истории непонятна. История по сути про тотальную некомпетентность по кругу.
Про некомпетентность технического руководителя заказчика.
Про некомпетентность того, кто контроллер менял (или это руководитель и был?)
Кто не смотрел в управлялку СХД.
Кто не смотрел в управлялки среды виртуализации (чай там не всё в порядке с путями было).
Кто кейс в поддержке у вендора закрывает без подтверждения по диагностике, что с СХД всё ок.
Вендора, у которого регулярно контроллеров на замену нет.
И сомнительный героизм лирического героя.
А рецептом предлагается ввести некоторую бюрократию и ответственность.
Что в целом то хорошо и инновацией не является.
Но кто ответственно и вдумчиво составит такие планы?
Сотрудники, некомпетентность которых продемонстрирована?
Или консалтинг, что всё проанализирует, денег возьмёт, означенные талмуды схемы и картинки нарисует?
Инструментарий ведения и поддержания в актуальном виде не предлагается. Excel?
Или брошюрованные талмуды в сейфе под роспись?
Вот про хороший и удобный инструментарий для не самой большой в мире компании было бы интересно.
А уж ежели даже про инструментарий. Коли рассказали подробно про категории алертов — то можно было бы например сказать, что во многих системах алертов: в том числе и на некоторых (не всех) СХД, и не только, есть часто такие функции как:
— aknowledge -подтвердить, что сообщение кто-то видел
— resolve — снять алерт, если система сама не сняла по устранению проблемы
Ну и комментарий во многих можно оставить (почти как комментарий к тому, почему Win собираетесь перезагрузить).
Да и что заходить в управлялку желательно под индивидуальной (доменной например) учёткой.
И чтобы правилом было, что алертов или warning неразрешённых висеть не должно.
И в результате не быть алерта, про который все знают, что есть, но никак не дойдут руки снять (а новый потом не заметят).
Т.е. сами эти алерты отчасти задачу планов решают.
Не говоря уже про системы мониторинга, CMDB и прочая по пути к светлому ITIL.
А если админ говорит, что боссу доложил и задачу выполнил, а реакции два месяца нет — планы не помогут.
А рецепт чтобы было всё нормально с СХД.
1) Компетентные сотрудники.
2) Нормальные СХД.
3) Нормальная поддержка и настройка отправки алертов тому, кто в них понимает.
Над примером планов, где «Потеря данных (продуктивных)» это средняя вероятность нарушения работы.
И которое индицируется «Всплывающим уведомлением».
И решается «Автоматическим восстановлением»…
поржал и призадумался. С этим то другой вопрос связан, на который ответа для себя толком за многие годы не нашёл за долгое время общения с СХД.
Бомбануло и поржал, поржал и бомбануло.
История выдуманная, много нестыковок, зачем написано — непонятно.
Единственный вывод — если в некомпетентные сотрудники, а тем более в руководстве — будет печально.
А лирический герой — д'Артаньян.
И при этом зачем-то про какие-то планы, какие-то СХД, какие-то алерты, которые лишь антураж для этой сюжетной линии.
спасибо за такое развернутое мнение. и за добавление про категории (пусть будет бонус-треком для дочитавших до самого конца) :))
прокомментируем хотя бы частично, по некоторым замечаниям.
История всё-таки из реальной жизни, и, как даже здесь, в комментариях, было отмечено, историй таких миллион. Тот очень редкий случай когда можно.
Зачем писали:
— Вы абсолютно правы — алерты и т.п. — по большей части лишь антураж, главная тема — люди, их компетенции и их желание организовать работу;
— табличка. некоторые наши заказчики уже брали её как заготовку и делали свой образец, до которого всё руки не доходили, глядишь и тут кому-то пригодится (ITIL, тем более работающий, есть далеко не у всех);
— надеемся (может, наивно), что заказчики прочитают, сделают правильные выводы, что и им пользу принесет и интеграторам с которыми работают, win-win, а не сидеть как в окопе до последнего, как это слишком часто бывает.
прокомментируем хотя бы частично, по некоторым замечаниям.
История всё-таки из реальной жизни, и, как даже здесь, в комментариях, было отмечено, историй таких миллион. Тот очень редкий случай когда можно.
Зачем писали:
— Вы абсолютно правы — алерты и т.п. — по большей части лишь антураж, главная тема — люди, их компетенции и их желание организовать работу;
— табличка. некоторые наши заказчики уже брали её как заготовку и делали свой образец, до которого всё руки не доходили, глядишь и тут кому-то пригодится (ITIL, тем более работающий, есть далеко не у всех);
— надеемся (может, наивно), что заказчики прочитают, сделают правильные выводы, что и им пользу принесет и интеграторам с которыми работают, win-win, а не сидеть как в окопе до последнего, как это слишком часто бывает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Alert-ы и Error-ы СХД, как с ними быть?