Comments 16
А то некоторые любят тестить по 6 месяцев… не не до конца уверены.
А как вы отказоусточивость тестируете? Система готова к link down но не готова к зависшей SPF, которая рапортует link up там, где его нет. Или, сетевой карте, которая делает shutdown из-за перегрева. Или фейловер работает хорошо, пока не начинается дребезг линка, и 300 up/down'ов в 60 секунд сносят крышу кластеру.
Как такие штуки воспроизводить?
Отключение линков, вылет диска, выключение узла / контроллера, сплит-брейн, имитация выключения ЦОДа для метро-кластера, исследование влияния ребилда кластера на производительность — это более встречающиеся случаи.
Как я уже писал в habr.com/ru/post/321178 — все начинается с модели угроз. Нет описанной угрозы — нет теста / защиты.
Во, вот тут вот и начинается интересное.
Приходит вендор с (новой, гиперконвергентной) супертехнологией. И есть сомнения — а насколько оно живуче? И вот сидит представитель вендора и предлагает заказчику пофантазировать на тему "что может сломаться внутри нашей коробочки". Откуда заказчику знать, что может сломаться? Вдруг, у вас там внутри неонка с кешом arp на 4 строчки и тут прилетает пятая? Или scsi шарит линк дисков и управления enclosure? В разборе полётов можно будет легко описать что stp не закрыло 8 линков и голова не смогла перезагрузить контроллер enclosure, но как об этом заказчику догадаться о такой возможности ДО наступления романтического события?
Т.е. требование номер один к внедрению новой гиперконвергентной суперсистемы — наличие такой компетенции внутри заказчика, которая способна, глядя на чёрный ящик с дерзким логотипом, сразу сказать "о, у них там внутри scsi, я знаю как ломать scsi", или "о, у них там используются SPF'ы на базе чипа CX-4431-X2, а я знаю, что на CX-4431-X2 есть erratra о том, что если приходит меньше десяти idle-фреймов, сбивается синхронизация, и через тысячу таких инцидентов оно начинает флапать, давайте им зададим такие условия тестирования, на которых эта бага воспроизводится".
… Надеюсь, вам понятно, что в ситуации, когда вендор с чёрным ящиком говорит "ну вы придумайте нам что у нас там внутри может сломаться", заказчик оказывается с чёрным ящиком… в смысле, котом в мешке.
Если у вас есть такая боль и печальный опыт — значит надо добавить такие тесты с измеряемым результатом и четкими критериями pass / fail.
После того, как я прошёлся по граблям особого типа, я уже знаю что бывают грабли особого типа. Но что делать, если у поставщика новая сияющая гиперконвергентная система гиперреактивной поставки грабель?
2. Спросить — а есть ли референсы?
3. Найти текущих пользователей, узнать у них напрямую чо как
4. Если заказчик большой, а слайды красивые — купить небольшую систему и нагрузить ее по самые помидоры, посмотреть как работает.
Только я повторю вопрос — какая связь краткого руководства по проведению *результативных* пилотов для инженеров вендора / партнера с конкретно вашей болью или общими размышлениями над сферической гиперковенргентной системой?
Иными словами, у вас есть критика самой статьи или изложенных в ней мыслей, а не рассуждения вокруг?
У меня есть критика самой индустрии, где:
- Царство несовместимостей
- Сырцы закрыты
- NDA по любому чиху
- GPL к реальной цене не относится от слова никак
- И постоянный FUD про конкурентов
И в этих условиях задача пилотного тестирования — продать и забыть.
Ну расскажите мне, про вендора, у которого продажи идут по GPL'ю. Прям интересно стало. Сколько там начальная скидка? 40%? 70%?
Краткое руководство по проведению пилотов и PoC