Tweet
Първо - изрично да подчертая че отдавна съм преболедувал клишето "...Майкрософт са най-тъпите, другите са по-добри, а пък Х е най-добър...". Просто попаднах на доста поучителен анализ как едно не камъче, а микроскопична прашинка може да обърне колата.
Историята:
- На 29 Февруари тази година услугата Microsoft Azure ("виртуален облак" с амнайсет хиляди сървъра) забива. Поради датата (29ти февруари) подозренията моментално падат върху софтуерен проблем свързан с високосната година. Ето го пълния анализ, а ето и съкратена версия:
- Проблемите започват от обработката на съобщения между виртуална машина и хоста и, операционна система на всеки от физическите Azure сървъри.
- Съобщенията между хост и виртуална машина са криптирани използвайки сертификат генериран от виртуалната машина.
- Сертификата е валиден една година. Съответно сертификат генериран от ВМ-ката на 29ти февруари 2012 изтича на 29 февруари 2013та. Понеже втората дата не съществува, целият процес на валидация на сертификата забива, което не позволява на ВМ-ката да тръгне.
- Хоста се опитва да подкара ВМ-ката на всеки 25 минути. След даден брой безуспешни опити обявява че има проблем с хардуера, и обявява целия сървър за компрометиран.
- Автоматичните системи които се разпореждат с клъстърите опитват да излекуват системата с редица рестартирания на ВМ-ките на "здравите" сървъри. Понеже и там сертификатите са ялови, сценарият протича по същия начин и проблемът се разпространява лавинообразно.
- При достигане на Х брой сървъри които са докладвали че са повредени, целият клъстър се поставя в авариен режим, прекратявайки "самолекуването" и програмните обновления за да се ограничат щетите.
- Черешката на тортата - при опита на инженерите на тъгъдък да разпространят код който да поправи бъга, се оказва че самият код е бъгясан в суматохата, от което системите гръмват пак.
Не давам акъл как е трябвало да се направи. Аз и толкова не бих могъл
Историята:
- На 29 Февруари тази година услугата Microsoft Azure ("виртуален облак" с амнайсет хиляди сървъра) забива. Поради датата (29ти февруари) подозренията моментално падат върху софтуерен проблем свързан с високосната година. Ето го пълния анализ, а ето и съкратена версия:
- Проблемите започват от обработката на съобщения между виртуална машина и хоста и, операционна система на всеки от физическите Azure сървъри.
- Съобщенията между хост и виртуална машина са криптирани използвайки сертификат генериран от виртуалната машина.
- Сертификата е валиден една година. Съответно сертификат генериран от ВМ-ката на 29ти февруари 2012 изтича на 29 февруари 2013та. Понеже втората дата не съществува, целият процес на валидация на сертификата забива, което не позволява на ВМ-ката да тръгне.
- Хоста се опитва да подкара ВМ-ката на всеки 25 минути. След даден брой безуспешни опити обявява че има проблем с хардуера, и обявява целия сървър за компрометиран.
- Автоматичните системи които се разпореждат с клъстърите опитват да излекуват системата с редица рестартирания на ВМ-ките на "здравите" сървъри. Понеже и там сертификатите са ялови, сценарият протича по същия начин и проблемът се разпространява лавинообразно.
- При достигане на Х брой сървъри които са докладвали че са повредени, целият клъстър се поставя в авариен режим, прекратявайки "самолекуването" и програмните обновления за да се ограничат щетите.
- Черешката на тортата - при опита на инженерите на тъгъдък да разпространят код който да поправи бъга, се оказва че самият код е бъгясан в суматохата, от което системите гръмват пак.
Не давам акъл как е трябвало да се направи. Аз и толкова не бих могъл
Дааа - за съжаление тези поблеми винаги са налице, няма как да се помисли за всичко 
"
Коментар