18-noyabr kuni UTC vaqti bilan soat 11:20 da (maqoladagi barcha vaqtlar shu hisob boʻyicha olingan) Cloudflare asosiy tarmoq trafigini yetkazib berishda jiddiy muammolarga duch kela boshladi. Shu sabab foydalanuvchilar mijozlarimizning saytlariga kirganda Cloudflare tarmog‘idagi xatolikni ko‘rsatadigan sahifa chiqdi.

Muammo hech qanaqa kiberhujum yoki zararli harakat tufayli yuzaga kelmagan. Aksincha, bunga bizning ma’lumotlar bazasi tizimlarimizdan biridagi ruxsatlar o‘zgargani sabab bo‘lgan. Shu o‘zgarish ma’lumotlar bazasining Bot Management tizimi ishlatadigan “feature file” (keyingi oʻrinlarda – “xususiyat fayli”) ichiga bir nechta yozuvlarni chiqarib yuborishiga olib kelgan. Natijada bu fayl ikki baravar kattalashgan. Kutilganidan katta bo‘lib qolgan fayl esa keyin tarmog‘imizdagi barcha serverlarga tarqalgan.

Tarmog‘imiz bo‘ylab trafikni yo‘naltiradigan dasturiy taʼminot bu faylni o‘qib, Bot Management tizimini doimiy o‘zgarib turadigan tahdidlarga moslab turadi. Ammo unda fayl hajmiga qo‘yilgan cheklov bor edi. Fayl ikki baravar kattalashgandan keyin bu cheklovdan oshib ketdi. Bu esa dasturiy taʼminotning ishdan chiqishiga olib keldi.

Boshida biz ko‘rayotgan muammo katta hajmdagi DDoS hujumi sababli yuzaga kelgan deb notoʻgʻri taxmin qildik. Lekin keyin asosiy sababni aniqladik. Shundan so‘ng kutilganidan katta faylning tarqalishini to‘xtatdik va uni avvalgi versiya bilan almashtirdik. 14:30 ga kelib, asosiy trafik deyarli odatdagidek ishlay boshladi. Keyingi bir necha soat davomida trafik qayta tiklangani uchun tarmog‘imizdagi yuklamani kamaytirish ustida ishladik. 17:06 ga kelib, Cloudflare’dagi barcha tizimlar normal holatga qaytdi.

Mijozlarimizga va umuman Internetga yetkazilgan noqulayliklar uchun uzr so‘raymiz. Cloudflare Internet ekotizimidagi muhim xizmatlardan biri bo‘lgani uchun bizning har qanday tizimimizdagi uzilishni qabul qilib bo‘lmaydi. Tarmog‘imiz ma’lum vaqt davomida trafikni yo‘naltira olmagani jamoamizning har bir a’zosi uchun juda og‘ir holat. Bu bilan sizni ranjitib qo‘yganimizni bilamiz.

Maqolada aynan nima bo‘lganini, qaysi tizim va jarayonlar ishlamay qolganini batafsil tushuntirib beramiz. Bu – biz rejalashtirayotgan ishlarning boshlanishi, lekin oxiri emas. Maqsadimiz shunday uzilish qayta takrorlanmasligini ta’minlash.

Uzilish

Quyidagi diagrammada Cloudflare tarmog‘i tomonidan koʻrsatilgan 5xx xatolik HTTP kodlari soni ko‘rsatilgan. Odatda bu ko‘rsatkich juda past bo‘ladi va uzilish boshlanguncha ham shunday boʻlgan.

Soat 11:20 gacha bo‘lgan hajm butun tarmog‘imiz bo‘ylab kuzatiladigan 5xx xatolarining kutilgan boshlang‘ich darajasini ko‘rsatadi. Grafikdagi keskin ko‘tarilish va keyingi tebranishlar esa noto‘g‘ri xususiyat fayli yuklangani sabab tizim ishlamay qolgani­ni bildiradi. E’tiborli jihati shundaki, tizimimiz ma’lum vaqt oralig‘ida o‘zini tiklardi. Bu ichki xatolik uchun juda noodatiy hol edi.

Sababi shundaki, fayl har besh daqiqada ClickHouse ma’lumotlar bazasi klasterida ishlaydigan so‘rov orqali yaratilardi. Klaster esa ruxsatlarni boshqarishni yaxshilash uchun bosqichma-bosqich yangilanayotgan edi. Noto‘g‘ri ma’lumot faqat so‘rov yangilangan qismda ishlaganda hosil bo‘lardi. Shu sabab har besh daqiqada tarmoqqa tez tarqaladigan yaxshi yoki yomon konfiguratsiya fayli paydo bo‘lishi ehtimoli bor edi.

Bu tebranishlar sabab vaziyatni tushunish qiyin bo‘ldi, chunki tizim bir tiklanib, bir ishlamay qolardi. Ba’zan yaxshi, ba’zan esa yomon konfiguratsiya fayli tarmoqqa tarqalardi. Dastlab bu bizni hujum bo‘layotgan bo‘lishi mumkin degan xulosa chiqarishga undadi. Oxir-oqibat, ClickHouse’dagi barcha tugunlar noto‘g‘ri konfiguratsiya faylini yarata boshladi va tebranishlar to‘xtab, tizim barqaror ravishda ishdan chiqish holatiga oʻtdi.

Xatoliklar 14:30 da asosiy muammo topilib, hal qilina boshlaguncha davom etdi. Muammoni hal qilish uchun yomon xususiyat faylining yaratilishi va tarqalishini to‘xtatdik. Keyin esa tizimga qo‘lda tekshirilib tasdiqlangan to‘g‘ri xususiyat faylini joylashtirdik. Shundan soʻng asosiy proksi tizimimizni majburan qayta ishga tushirdik.

Yuqoridagi diagrammadagi qolgan uzun qism jamoamiz nosoz holatga tushgan xizmatlarni qayta ishga tushirishini ko‘rsatadi. Soat 17:06 da 5xx xatolik kodi hajmi me’yoriy holatga qaytdi.

Quyidagi xizmatlarga taʼsir koʻrsatildi:

HTTP 5xx xatoliklari qaytarilishidan tashqari ta’sir davrida CDN’dan kelayotgan javoblarning kechikishi ham sezilarli darajada oshdi. Buning sababi – tizimdagi ushlanmagan xatolarga qo‘shimcha diagnostika ma’lumotlarini avtomatik qo‘shadigan debugging va kuzatuv tizimlari juda ko‘p CPU resursini ishlatgani edi.

Cloudflare so‘rovlarni qanday qayta ishlaydi va jarayonda nima xato ketdi

Cloudflare’ga keladigan har bir so‘rov tarmog‘imizda aniq belgilangan yo‘ldan o‘tadi. Bu – brauzer veb-sahifani yuklayotgani, mobil ilova API chaqirayotgani yoki boshqa xizmatdan kelayotgan avtomatik trafik bo‘lishi mumkin. So‘rovlar avval HTTP va TLS qatlamida qabul qilinadi, keyin asosiy proksi tizimimiz (Frontline, biz uni FL deymiz)ga o‘tadi. Oxirida esa kesh-qidiruvlarni amalga oshiradigan yoki zarurat tug‘ilganda asl manbadan ma’lumotlarni oladigan Pingora orqali o‘tishiga toʻgʻri keladi.

Biz ilgari asosiy proksining qanday ishlashi haqidagi batafsil ma’lumotni shu yerda ulashgan edik.

So‘rov asosiy proksi orqali o‘tayotganda biz tarmog‘imizdagi barcha xavfsizlik va samaradorlik xizmatlarini ishga tushiramiz. Proksi har bir mijozning o‘ziga xos sozlamalarini qo‘llaydi: WAF qoidalarini bajarish, DDoS himoyasini faollashtirishdan tortib trafikni Developer Platform yoki R2 ga yo‘naltirishgacha. Bularning barchasi maxsus modullar orqali amalga oshiriladi. Bu modullar proksidan o‘tayotgan trafikga kerakli konfiguratsiya va siyosat qoidalarini qo‘llaydi.

Oʻsha modullardan biri – Bot Management bugungi uzilishning sababchisi bo‘ldi.

Cloudflare’ning Bot Management tizimi boshqa imkoniyatlar qatori tarmog‘imizdan o‘tayotgan har bir so‘rov uchun “bot ballari”ni hosil qiladigan mashina o‘rganishi modelini ham o‘z ichiga oladi. Mijozlarimiz esa shu bot ballaridan foydalanib, qaysi botlarga saytlariga kirishga ruxsat berish yoki taqiqlashni boshqaradi.

Model kirish sifatida “feature” (keyingi oʻrinlarda – “xususiyat”) konfiguratsiya faylidan foydalanadi. Bu yerda “xususiyat” – so‘rovning avtomatlashtirilgan yoki yo‘qligini bashorat qilish uchun mashina o‘rganishi modeli foydalanadigan alohida belgi. Xususiyat konfiguratsiya fayli esa ana shu alohida belgilar to‘plamidan iborat.

Bu xususiyat fayli har bir necha daqiqada yangilanadi va butun tarmoqqa tarqatiladi. Bu esa bizga Internetdagi trafik o‘zgarishlariga tezkor munosabat bildirish imkonini beradi. Yangi bot turlari yoki yangi bot hujumlariga qarshi tez choralar ko‘rishimiz ham shu fayl orqali amalga oshadi. Shuning uchun bu fayl tez-tez va tezkor tarqatilishi juda muhim, chunki niyati yaxshi boʻlmagan shaxslar taktikani tez o‘zgartiradi.

Quyida tushuntiriladigan ClickHouse so‘rovining ishlashidagi o‘zgarish ushbu faylni yaratishda juda ko‘p takrorlanuvchi “xususiyat” qatorlari paydo bo‘lishiga sabab bo‘ldi. Natijada oldin o‘lchami aniq bo‘lgan xususiyat konfiguratsiya faylining hajmi kattalashdi va bu botlar modulida xatolik yuzaga keltirdi.

Oqibatda mijozlarimiz trafigini qayta ishlash bilan shug‘ullanadigan asosiy proksi tizimi botlar moduliga bog‘liq bo‘lgan har qanday trafik uchun HTTP 5xx xato kodlarini qaytardi. Bu holat Workers KV va Access xizmatlariga ham ta’sir qildi, chunki ular ham asosiy proksiga bog‘langan.

Bu hodisaga aloqasi bo‘lmagan holda biz mijozlar trafikini ichki nomi FL2 bo‘lgan yangi proksi xizmatiga o‘tkazayotgan edik va hozir ham o‘tkazyapmiz. Muammo ikkala versiyaga ham ta’sir qildi, lekin ta’sir darajasi har xil boʻldi.

Yangi FL2 proksi dvigatelida ishlayotgan mijozlar HTTP 5xx xatoliklarini ko‘rishdi. Eski proksi – FL’da ishlayotgan mijozlar xatolarni ko‘rishmadi, biroq bot ballari to‘g‘ri shakllantirilmadi, natijada barcha trafik nol bot ballini oldi. Botlarni bloklash qoidalariga ega bo‘lgan mijozlar ko‘plab soxta ijobiy natijalarni ko‘rgan bo‘lardi. Qoidalarida bot ballaridan foydalanmaydigan mijozlarda esa hech qanday ta’sir bo‘lmadi.

Bizni chalg‘itgan va bu hujum bo‘lishi mumkin degan fikrga olib kelgan yana bir koʻzga tashlanarli belgi bor edi: Cloudflare’ning status sahifasi ham ishlamay qoldi. Status sahifasi Cloudflare infratuzilmasidan butunlay mustaqil, unga hech qanday bogʻliqligi yoʻq. Keyin ma’lum bo‘lishicha, bu shunchaki tasodif edi. Lekin muammoni tahlil qilayotgan jamoaning ayrim a’zolarida hujumchi ham tizimlarimizga, ham status sahifamizga bir vaqtning o‘zida hujum qilayotgandek taassurot uyg‘otdi. O‘sha vaqtda status sahifasiga kirgan foydalanuvchilar xatolik xabariga duch kelishdi.

Ichki hodisalar muhokamasida bu yaqinda bo‘lib o‘tgan katta hajmdagi Aisuru DDoS hujumlarining davomi bo‘lishi mumkin, deb xavotirlandik.

So‘rovning o‘zgarishi

Yuqorida aytganimdek, so‘rov ishlashidagi o‘zgarish xususiyat faylida juda ko‘p takrorlanuvchi qatorlar paydo bo‘lishiga sabab bo‘ldi. Ko‘rib chiqilayotgan ma’lumotlar bazasi tizimi ClickHouse dasturiy ta’minotidan foydalanadi.

Tushunish uchun ClickHouse’da tarqatilgan so‘rovlar qanday ishlashini bilish foydali. ClickHouse klasteri ko‘plab shardʼlardan iborat bo‘ladi. Barcha shardʼlardagi ma’lumotlarni so‘rash uchun default nomli bazada Distributed (ya’ni Distributed jadval dvigateli) yordamida yaratilgan maxsus tarqatilgan jadvallar mavjud. Distributed dvigateli esa r0 nomli bazadagi asosiy jadvallarga murojaat qiladi. Ma’lumotlar ana shu asosiy jadvallarda, ya’ni ClickHouse klasterining har bir shardʼida saqlanadi.

Tarqatilgan jadvallarga yuborilgan so‘rovlar umumiy (shared) tizim akkaunti orqali ishlaydi. Taqsimlangan so‘rovlarimizning xavfsizligi va ishonchliligini oshirish maqsadida ularni dastlabki foydalanuvchi hisoblari ostida bajarish bo‘yicha ishlar olib borilmoqda.

Bugungacha ClickHouse foydalanuvchilari system.tables yoki system.columns kabi ClickHouse tizim jadvallaridan jadval metama’lumotlarini so‘raganlarida faqat default (asosiy) bazadagi jadvallarni ko‘rishardi.

Foydalanuvchilar allaqachon r0 ichidagi asosiy jadvallarga bilvosita kirish huquqiga ega bo‘lgani uchun 11:05 da biz bu kirishni oshkora (explicit) qilish bo‘yicha o‘zgartirish kiritdik. Shunda foydalanuvchilar ushbu jadvallarning metama’lumotlarini ham ko‘ra olardi. Distributed subquery’lar dastlabki foydalanuvchi nomidan bajarilishiga ishonch hosil qilish orqali soʻrov limitlari va kirish huquqlarini yanada aniqroq baholash mumkin bo‘ladi. Bu esa bitta foydalanuvchining yomon subquery’si boshqalarga ta’sir qilishining oldini oladi.

Yuqorida tushuntirilgan o‘zgarish barcha foydalanuvchilarga o‘zlari kirish huquqiga ega bo‘lgan jadvallar haqidagi aniq metama’lumotlarni olish imkonini berdi. Afsuski, ilgari shunday bir taxmin qilingan edi: bunday so‘rov qaytargan ustunlar ro‘yxati faqat “default” ma’lumotlar bazasini o‘z ichiga oladi, deb o‘ylangan:

SELECT 
  name, 
  type 
FROM system.columns 
WHERE 
  table = 'http_requests_features' 
order by name;

So‘rovda ma’lumotlar bazasi nomi bo‘yicha filtr qo‘yilmaganiga e’tibor bering. Ma’lum bir ClickHouse klasteri foydalanuvchilariga bosqichma-bosqich aniq ruxsatlar berishni boshlaganimiz sababli 11:05 dagi o‘zgarishdan keyin yuqoridagi so‘rov ustunlarning “dublikatlari”ni qaytara boshladi. Chunki bu ustunlar r0 ma’lumotlar bazasida saqlangan asosiy jadvallarga tegishli edi.

Afsuski, yuqorida aytilgan o‘sha turdagi so‘rov Bot Management funksiyasining xususiyat faylini yaratish jarayonida ishlatilgandi. Faylga kiritiladigan har bir “xususiyat” aynan shu so‘rov asosida shakllantirilgan.

Yuqoridagi so‘rov quyidagiga o‘xshash (soddalashtirilgan) ustunlar jadvalini qaytarardi:

Biroq foydalanuvchiga berilgan qo‘shimcha ruxsatlar tufayli javob endi r0 sxemasidagi barcha metadata ma’lumotlarini ham o‘z ichiga oldi. Natijada javobdagi qatorlar soni ikki baravardan ko‘proq oshib ketdi va bu yakuniy fayldagi qatorlar (ya’ni xususiyatlar) soniga ta’sir qildi.

Xotirani oldindan ajratish

Bizning proksi servisda ishlaydigan har bir modul cheksiz xotira sarflanishining oldini olish va unumdorlikni oshirish uchun xotirani oldindan ajratib qo‘yadigan bir qator cheklovlarga ega. Mazkur holatda Bot Management tizimi runtime jarayonida ishlatilishi mumkin bo‘lgan mashina o‘rganishi (ML) xususiyatlari soniga ega cheklov bilan ishlaydi. Hozirda bu limit 200 ta qilib belgilangan, biz aslida foydalanadigan xususiyatlar soni taxminan 60 ta. Yana takrorlaymiz, bu limit mavjudligining sababi – samaradorlik nuqtayi nazaridan bu xususiyatlar uchun xotirani oldindan ajratib qo‘yish zarurdir.

Nosoz fayl 200 dan ortiq xususiyatlar bilan serverlarimizga tarqalganida bu limit buzildi – natijada tizim ishdan chiqdi. Quyida ushbu tekshiruvni amalga oshirgan va xatoni qayta ishlamagan FL2 Rust kodi keltirilgan:

Bu quyidagi ishdan chiqishga olib keldi, o‘z navbatida, 5xx xatosini keltirib chiqardi:

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

Hodisa vaqtida yuzaga kelgan boshqa ta’sirlar

Bizning asosiy proksi tizimimizga tayanuvchi boshqa xizmatlar ham ushbu hodisadan zarar ko‘rdi. Bunga Workers KV va Cloudflare Access kiradi. 13:04 da jamoa Workers KV uchun asosiy proksini chetlab o‘tuvchi patch joriy qilib, ushbu tizimlarga ta’sirni kamaytirishga muvaffaq bo‘ldi. Shundan so‘ng Workers KVʼga tayanadigan barcha quyi tizimlar (jumladan, Accessʼning o‘zi) xatolik darajasining pasayganini kuzatdi.

Cloudflare Dashboard ham ta’sirga uchradi. Chunki ichki jarayonlarda Workers KV ishlatiladi va login jarayonida Cloudflare Turnstile qo‘llanadi.

Turnstile ham uzilishdan ta’sirlandi, natijada faol boshqaruv paneli seansiga ega bo‘lmagan mijozlar tizimga kira olishmadi. Bu holat grafikda ko‘rsatilganidek, ikki vaqt oralig‘ida mavjudlikning pasayishi ko‘rinishida namoyon bo‘ldi: 11:30 dan 13:10 gacha va 14:40 dan 15:30 gacha.

Birinchi davr (11:30 dan 13:10 gacha) ba’zi boshqaruv paneli va control plane funksiyalari tayanadigan Workers KV’dagi nosozlik sababli yuz berdi. 13:10 da Workers KV asosiy proksi tizimini chetlab o‘tgach, bu muammo bartaraf etildi. Boshqaruv panelidagi ikkinchi muammo davri esa xususiyat konfiguratsiya ma’lumotlari tiklangandan keyin yuzaga keldi. Tizimga kirish bo‘yicha to‘plangan (backlog) urinishlar boshqaruv panelini ortiqcha yuklay boshladi. Bu backlog qayta urinishlar bilan qo‘shilib, kechikishning oshishiga va dashboard mavjudligining pasayishiga olib keldi. Control plane’ning bir vaqtning o‘zida bajariladigan jarayonlarini kengaytirish (scaling concurrency) taxminan 15:30 da dashboardʼni to‘liq tikladi.

Tuzatish va keyingi qadamlar

Endi tizimlarimiz qayta ishga tushdi va normal ishlayapti, bunday holatlar kelajakda takrorlanmasligi uchun ularni yanada mustahkamlash ustida ish allaqachon boshlandi. Xususan, biz quyidagilarni amalga oshirmoqdamiz:

• Cloudflare tomonidan yaratiladigan konfiguratsiya fayllarini qabul qilish jarayonini foydalanuvchi tomonidan kiritiladigan ma’lumotlar kabi nazorat qilish.

• Funksiyalar uchun ko‘proq global to‘xtatish tugmalarini faollashtirish.

• Core dumpʼlar yoki boshqa xato hisobotlarining tizim resurslarini to‘liq egallab olish imkoniyatini yo‘q qilish.

• Barcha asosiy proksi modullaridagi xato holatlari uchun yuzaga kelishi mumkin bo‘lgan nosozliklarni qayta ko‘rib chiqish.

Bu kun Cloudflare uchun 2019-yildan beri kuzatilgan eng yomon avariya bo‘ldi. Ba’zi uzilishlar bizning boshqaruv panelimiz ishlamasligiga sabab bo‘lgan. Yana ba’zilari yangi funksiyalarning vaqtincha ishlamasligiga olib kelgan. Ammo so‘nggi 6+ yil ichida asosiy trafikning aksariyati tarmog‘imiz orqali o‘tmasligiga sabab bo‘lgan boshqa uzilish yuz bermagan edi.

Bu galgi uzilissh mutlaqo qabul qilib bo‘lmaydigan holatdir. Biz tizimlarimizni doimo trafik oqimini ta’minlay oladigan darajada bardoshli qilib yaratganmiz. O‘tmishdagi uzilishlar har doim yangi, yanada chidamliroq tizimlarni yaratishimizga turtki bo‘lgan.

Butun Cloudfare jamoasi nomidan Internetga yetkazilgan noqulayliklar uchun uzr soʻrayman.

Manba: “Cloudflare outage on November 18, 2025”