Google най-накрая разкри как случаен ред код парализира половината интернет миналата седмица
Всички чакаха пояснение за неуспеха. Сега към този момент е ясно: това не е случайност, а причинност...
Емил Василев преди 15 секунди 0 СподелиНай-четени
ТелефониСветослав Димитров - 12:26 | 12.06.2025Следните знаци на екрана на вашия смарт телефон демонстрират, че е допустимо да сте следени
НаукаЕмил Василев - 15:23 | 13.06.2025Пропуски в глобите разрешиха на Китай да сътвори цялостен индустриален цикъл на фотонни чипове
ТелефониСветослав Димитров - 12:31 | 12.06.2025Защо телефоните с бутони ще станат известни още веднъж през 2025 година
Емил Василевhttps://www.kaldata.com/Миналата седмица интернет по целия свят беше в несигурно положение – Cloudflare, Spotify, Discord, Snapchat, Twitch и доста други услуги започнаха всеобщо да отхвърлят. Инфраструктурата на Гугъл Cloud беше в центъра на събитията: на 13 юни за съвсем три часа клиентите по целия свят изгубиха достъп до наетите облачни запаси. Инцидентът провокира резонанс освен поради мащаба си, само че и тъй като проблемите се разпространиха каскадно – от самата Гугъл към услугите, които са свързани с нея.
Сега корпорацията публично даде техническо пояснение за случилото се.
Както и в редица други огромни произшествия през последните години, в основата на казуса не е злоумишлен хакер или външна офанзива, а неточност в кода, който е бил осъществен в системата за ръководство на квотите. Повредата се оказа толкоз сериозна, че засегна няколко равнища на инфраструктурата, в това число връзките и мониторинга.
Всичко стартира с дребна актуализация: на 29 май съставният елемент Service Control – основен модул, виновен за инспекцията на квотите и политиките на API в облака беше обновен, с цел да поддържа спомагателна логичност за надзор на ресурсите. Този съставен елемент играе значима роля в архитектурата на Гугъл Cloud, като обслужва поръчките посредством разпределени районни инстанции и постанова ограничавания на квотите, разрешенията и политиките за достъп.
Нововъведението мина през общоприетия поетапен развой на внедряване по райони и на стадия на внедряване всичко изглеждаше добре. Имаше обаче една специфичност: модифицираният код се активираше единствено при избрани условия – когато влизаше в действие нова политика със характерна конструкция на данните, а тъкмо тази политика не беше задействана на стадия на тестване. Ето за какво проблематичният откъс от кода не се прояви нито в средата за внедряване, нито по време на районното разрастване. Той просто дремеше в системата и чакаше задействане.
Критичният миг настъпи на 12 юни, когато в една от политиките бяха добавени полета с празни стойности. Това беше спусъкът, който започва неразучен до тогава път за осъществяване на код.
Новият откъс се опита да получи достъп до изчезналите данни и се натъкна на неточност с нулев справочник. Резултатът беше незабавен срив на бинарната стратегия, отговаряща за Service Control и рестартиране. И казусът се случи синхронно във всички райони, защото всеки район четеше същите политики и изпълняваше същата верига от дейности.
Гугъл удостовери, че кодът не е бил предпазен с байрак ficha – механизъм, който нормално разрешава да се забрани непоследователната активност когато и да е, преди да стартира всеобщото разпространяване. Ако флагът беше употребен, инженерите щяха да съумеят да разпознават и изолират казуса стремително. В този случай обаче той просто не е бил очакван. Липсвала е и обработка на грешките в кода, което е направило повредата невъзможна за премахване без ръчна интервенция.
Екипът на Гугъл за ръководство на ресурсите реагира бързо: случаят беше отхвърлен след 2 минути, повода беше избрана за към 10 минути, а след 40 инженерите започнаха възобновяване, само че проблемите не свършиха дотук.
В огромни райони, като us-central1, рестартирането на Service Control провокирало претоварване на свързаната инфраструктура. Механизмът, предопределен за планувана работа не бил квалифициран за лавината от повтарящи се поръчки, което провокирало „ резултата на стадото “ – когато сходни процеси стартират по едно и също време да получават достъп до обща взаимозависимост.
Тъй като Service Control е разпределена система, претоварването в огромните местоположения се получи каскадно, което затрудни възобновяване. В някои райони възобновяване лиши съвсем три часа. В същото време продуктите на Гугъл, свързани с Service Control започнаха да излизат от строя един след различен: Gmail, Drive, Meet, Calendar, Voice – всички те претърпяха сривове в друга степен, a клиентите на Cloudflare, чиято услуга Workers KV разчита на Гугъл Cloud се сблъскаха с неуспех при 90% от поръчките.
И въпреки че множеството системи бяха възобновени и заработиха до вечерта на 13 юни, последствията от случая към момента се отстраняват. От Гугъл дадоха обещание освен да не повтарят същите неточности, само че и да създадат структурни промени в процеса на работа с инфраструктурен код. По-специално, Гугъл счита да усъвършенства както автоматизираната, по този начин и ръчната връзка с клиентите, тъй че информацията за сериозни повреди да доближава до тях по-бързо и по-точно.
Стигна се и до значим извод: инфраструктурата за известяван и наблюдаване би трябвало да бъде изолирана от останалата част на облака, с цел да продължи да действа даже при положение на световно спиране.
