Weimob, yedi gün ve gece boyunca veri tabanındaki verileri alıp sildi ve satıcıya 150 milyon yuan ödemeye karar verdi. Buluta gitmek acı vericiydi.
İçbükey tapınaktan on üç Qubit Raporu | Genel Hesap QbitAI
"Yedi gün ve gece, Weimeng'in silinen verileri tamamen kurtarıldı!"
1 Mart akşamı Weimob, ortağı Tencent Cloud'un da yardımıyla, Veriler tamamen kurtarıldı Veri kurtarma işleminin 3 Mart 2020 tarihinde saat 9'da tamamlanması ve çevrimiçi olması bekleniyor.
Tencent Cloud'un resmi Weibo da veri kurtarmanın karmaşıklığının herkesin hayal gücünün ötesinde olduğunu belirten bir mesaj yayınladı, "Sürekli olarak bütün gece, tüm zorlukların üstesinden gelin ve sonunda başarılı olun!"
Bununla birlikte, veriler kurtarılmış olmasına rağmen, kayıp hala ciddiydi.
Kaza, 23 Şubat akşamı Weimobun SaaS işi aniden çöktüğünde meydana geldi. Weimob'u temel alan tüccarlar için küçük programlar tamamen durdu ve 3 milyon tüccarın işi temelde durdu.
Ve bu ciddi kazanın nedeni, Weimeng'in bir çalışanıydı ve şirketin veri tabanını kendi başına silmiş ve birikmiş piyasa değeri 3 milyar HK $ 'dan fazla kaybetmiştir.
Kazanın tüccarlar üzerindeki etkisiyle ilgili olarak Weimob şunları söyledi:
Yönetim suçlu ve suçlu hissediyor ve hazır 150 milyon yuan RMB tazminat hükmü, Şirket 100 milyon yuan varsayıyor , Yönetim 50 milyon yuan varsayıyor .
"Şaka" gibi olaylardan sonra, işletmeler için bir uyandırma çağrısı yaptı - "veri güvenliği gökyüzünden daha büyüktür".
150 milyon yuan tazminat, tamamen bulutlamaya karar verdi
Bugün Weimob, resmi web sitesinde kaza ve onarım sürecinin yanı sıra tazminat planı ve veri güvenliği planını açıklayan gönüllü bir "SaaS İş Üretim Ortamı ve Veri Kurtarma" duyurusu yayınladı.
Kaza ve onarım süreci
23 Şubat 2020'de, şirketin çalışanlarının şirketin SaaS iş üretim ortamını ve verilerini kasıtlı olarak sabote etmesi nedeniyle, şirket müşterilere SaaS ürünlerini geçici olarak sağlayamadı. Şu anda çalışan, Şanghay Kamu Güvenliği Bürosu Baoshan Şubesi tarafından cezai bir şekilde gözaltına alındı.
25 Şubat 2020'de şirket, temel SaaS işinin üretim ortamını sürdürdü. SaaS işinin yeni kullanıcıları, şirketin SaaS ürünlerini kullanmaya devam edebilir. Şirket ayrıca, işletmelerin veri kurtarmadan önce devam edebilmesini sağlamak için eski kullanıcılar için geçici geçiş planları sunar. İşletme.
28 Şubat 2020'de şirket, tüm SaaS işletmelerinin üretim ortamını geri yükledi, eski kullanıcılar için oturum açma bilgilerini açtı ve mikro site ürünlerinin tüm yedekleme verilerini geri yükledi.
1 Mart 2020 saat 20.00 itibariyle, Tencent Cloud'un yardımıyla, şirketin yedeklenen verileri kurtarıldı. Bu seferki büyük miktarda veri nedeniyle, veri tutarlılığını ve çevrimiçi deneyimi sağlamak için şirket, 2 Mart 2020 tarihinde 02: 00-08: 00 saatleri arasında bir veri kurtarma alıştırması gerçekleştirecek. Bu süre zarfında, şirketin sistemi Hizmet askıya alınacak ve sistem verileri, alıştırma tamamlandıktan sonra 2 Mart 2020'deki verilere geri döndürülecek.
Şirket verileri resmi olarak çevrimiçi olarak 2 Mart 202022:00 ile 3 Mart 2020 saat 09:00 arasında devam ettirecektir. Şirket, verileri 23 Şubat 2020 ve öncesinde geri yükleyecek ve verileri 23 Şubat 2020 ile 2 Mart 2020 tarihlerinde birleştirecek ve o zamana kadar veri kurtarma tamamlanacaktır.
Bu kaza için tazminat planı
Bu kazanın şirketin SaaS iş tüccarları üzerindeki olumsuz etkileri ve kayıpları göz önüne alındığında, şirketin yönetimi, tüccar tazminat planlarını incelerken veri kurtarmaya odaklanıyor.
Bu kazanın getirebileceği potansiyel nakit ödeme ve akış ödemesine yanıt olarak, şirket ve şirket yönetimi, 100 milyon RMB'si şirket tarafından ve 50 milyon RMB'si şirket yönetimi tarafından karşılanacak toplam 150 milyon RMB tazminat fonu hazırladı. Taahhüt, şirket ve yukarıda belirtilen şirket yönetimi, belirli tazminatı verirken yukarıda açıklanan limit dahilinde orantılı olarak ödeme yapacaktır.
Veri Güvenliği Planı
Kaza, çalışanların uygunsuz davranışlarından kaynaklansa da, şirketin veri güvenliği yönetimindeki eksikliklerini de ortaya çıkardı.
Bu amaçla, şirket harici veri güvenliği uzmanlarını şirkete, esas olarak üretim ortamının ve veri izinlerinin hiyerarşik yönetimini ve yürütülmesini, verileri Tencent bulut veritabanına aktarmayı ve kazalara hızlı müdahaleyi güçlendirmeyi kapsayan veri güvenliği koruma planlarını formüle etme ve değerlendirme konusunda yardımcı olmaya davet etti. İşletme ve bakım personelinin becerisi ve yasal ve mesleki etik bilgisi.
Şirket, bu tür kazaların tekrarını önlemek için yukarıdaki veri güvenliği önlemlerini kademeli olarak uygulamaktadır.
Verileri yedi gün yedi gecede geri yüklemek neden bu kadar uzun?
Aslında, birçok yaygın yazılım çökmesi yaşadık. Örneğin, geçen yıl 5 Aralık'ta Alipay ağı titredi ve WeChat resmi hesabı 26 Aralık'ta çöktü. Ancak, Tencent ve Alibaba'nın kurtarma süresi, her biri yalnızca% 25 ile nispeten hızlıydı. Dakikalar ve 45 dakika.
Weimob veritabanı bu kez silindi Tencent Cloud işbirliği ile neden 7 gün 7 gece sürdü?
Bu bağlamda, yazılım kalitesi ve Ar-Ge mühendisliği verimliliği konusunda sektörün tanınmış pratik uzmanları Ru Bingsheng , Bazı görüşleri ifade etti, ana sebep Teknoloji çok karmaşık .
Anlamanız gereken ilk şey, veritabanının işletim ortamıdır.Basitleştirmek için üç ana tür vardır: "Bulut Yok", "Tam Bulut" ve "Sahte Bulut".
"Bulut Yok" Kendi veri merkezinde inşa etmeyi ve donanımı, yazılımı ve verileri tamamen kendi başına yönetmeyi ifade eder.Bu, bulut platformlarının yaygınlaşmasından önceki temel uygulamadır.
"Hepsi bulutta" Tamamen bulut ortamı üzerine inşa edilmiş olmak demektir. Buradaki bulut, genel bir bulut veya özel bir bulut olabilir.
"Sahte Bulut" Bulut çözümü sanal makine olarak kullanılmaktadır. Bu yöntem yukarıdaki "buluta gitmeme" yöntemine benzer. Bulutun avantajlarından iyi yararlanmaz, sadece veri merkezindeki makineleri buluta taşır.
Yukarıdaki üç yöntem için, "buluta gitmemek" ve "sahte buluta gitmemek" veriler için "tümü buluta gitmekten" daha risklidir.
Operasyon ve bakım personelinin "buluta gitmeme" ve "sahte buluta gitme" durumunda "rm -rf / *" ve "fdisk" gibi ekstrem işlemleri gerçekleştirme şansına sahip olma olasılığı daha yüksektir.
"Tam bulut" ile, bu tür komutları işletim sistemi seviyesinden yürütme fırsatına sahip olmak daha zordur ve veritabanı verileri rm -rf / tarafından silinmeyecektir.
Benzer şekilde, verilerin yanlış çalışması sorunuyla karşı karşıya kalan "tam bulut erişimi", "bulut erişimi olmaması" ve "sahte bulut erişimi" ne göre bariz avantajlara sahiptir.
Tencent Cloud'un önceki yanıtından, muhtemelen Weimeng'in silinen verilerinin Tencent Cloud'da olmadığını görebiliriz. Mevcut veri kurtarma hızıyla birleştiğinde, Weimeng'in "tam bulutu" benimsememiş olma olasılığının yüksek olduğu hemen hemen belirlenebilir. Mimari veya verilerin sadece bir kısmı buluttadır.
Bu durumda tüm verileri kurtarmak için teknik zorluğun çok büyük olduğu düşünülebilir.
Ru Bingshengin anlayışına göre, en azından aşağıdaki teknik engellerin aşılması gerekir:
Tam yedek alın Uzaktan soğuk yedekleme veya felaket kurtarma varsa, bu ideal bir durumdur, ancak tam yedekleme genellikle çok büyük olduğu için dosya aktarımını ve doğrulamayı tamamlamak uzun zaman alır.
Artımlı yedekleme alın Çoğu durumda, artımlı yedeklemelerin uzaktan felaket kurtarma yedeklemeleri yapacak zamanı yoktur, bu nedenle diskten geri yükleme olasılığı yüksektir, bu da çok fazla zaman alır ve% 100 tam geri yükleme garanti edilemez.
Binlog alın Binlog, tüm veritabanı tablo yapısı değişikliklerini (CREATE, ALTER TABLE vb.) Ve tablo veri değişikliklerini (INSERT, UPDATE, DELETT, vb.) Kaydeden ikili bir günlük dosyasıdır. Dosya boyutu küçük değil ve sayı da büyük.
Temel girdi olarak yukarıdakilerle, veritabanı düzeyinde veri içe aktarma ve kurtarma çalışması başlatılabilir.Bu işlem de çok zaman alır ve bu, yukarıdaki dosyaların% 100 elde edilebileceği varsayımına dayanır.
Veritabanı veri dosyaları ve yedekleme dosyaları genellikle çok büyüktür, bu nedenle tek tek veri alanları yeniden yazıldığı sürece geri yüklenen dosyalar eksiktir. Şu anda düzeltmeler yapmak için insan müdahalesi gerekir. Bu iş yükü ve teknik zorluk Çok büyüktür ve bazen özel ekipman gerektirir.
Ayrıca Weimeng kadar büyük bir sistem için, her dikey iş birimi kendi iş veritabanına sahip olabilir, hatta bu veritabanları farklı çözümler benimseyebilir, mimarideki bu heterojenlik de kurtarma sürecini beraberinde getirecektir. Harika meydan okuma.
Ek olarak, verilerin bir kısmı geri yüklense bile, hemen başlatılamaz ve diğer ilgili veriler geri yüklenmelidir ve verilerin kusursuz olduğundan emin olmak için verilerin çapraz kontrol edilmesi gerekir, bu da çok zaman gerektirir.
Lenovo Cloud Collar Veri Güvenliği Laboratuvarı Başkanı Zhao Zhen Ayrıca, aşırı veri ölçeğinin, veri kurtarma uygulamasındaki zorluklardan biri olduğuna inanılmaktadır.
Teknik çözüm nispeten olgun olduğundan, manuel verimlilik bir darboğaz değildir Sabit disk G / Ç hızı hesaplanarak, tüm kurtarma sürecinin zamanlaması kabaca değerlendirilebilir. Bununla birlikte, büyük miktarda veri, hata tolerans oranını azaltacak ve insan veya ekipmanın neden olduğu her hata, çok fazla ekstra kurtarma süresini artıracaktır.
Aynı zamanda, aşırı veri ölçeği, kurtarma için gereken kaynakları da artıracak ve bu da genel kurtarma maliyeti üzerinde büyük bir etkiye sahip olacaktır.
Veri güvenliği günden fazla
Bu savaştan sonra veri güvenliğinin önemini de fark ettik ve bu tür veri kayıplarının nasıl önleneceği de daha fazla kişi tarafından tartışılmaya başlandı.
Gelip övgüde bulunan bazı insanlar var:
Genel hesap "Chengge's World", şirketlerin bulut veritabanı ürünlerini kullanabileceğini öne sürüyor, çünkü genel bulut satıcıları nispeten tam otomatik yedekleme ve kurtarma mekanizmalarına sahip ve silinme şansı yok, yedekleme yapın, tam yedeklemeler yapın ve artımlı yedeklemeler yapın. , Yedeklemeleri geciktirin ve saha dışında birden çok bilgisayar odasını yedekleyin; kontrol izinlerini yönetin, yüksek riskli komutları engellemek için ana bilgisayar güvenlik kontrol yazılımını veya kale makinelerini kullanın; yasaları yaygınlaştırın, uyarılar verin ve ilgili personelin bu konuda düşünmesini önleyin.
Ancak Zhihu kullanıcıları "boş yere boş", şirketlerin hassas veri işlemleri için çifte onay gerektiren bir çift inceleme mekanizması kurmalarını, gerçek zamanlı veri yedeklemesi için uzaktan felaket kurtarma veya eşzamansız iletişim kullanmalarını; önemli uygulama hizmetleri için bir veritabanı silme izleme mekanizması kurmalarını önerdi. Önemli işlemleri yaparken onaylamanız gerekir.
Ve Ru Bingsheng'in bu veri kurtarmanın teknik zorluklarına ilişkin analizinden, "tümü bulutta" nın nispeten güvenli olduğu da görülebilir.
Ancak aynı zamanda bazı okuyucular bir mesaj ve geri bildirim bıraktı:
Bir bulut yöneticisi olarak, buluttaki tüm veriler yine de silinebilir. Herhangi bir bulutun bir başlatma aracı vardır, tüm bulut güvenliği başkalarına devretmek içindir.
Yani soru şu: "Hepsi bulutta" veya "Hepsi bulutta değil" hakkında ne düşünüyorsunuz?
Portal
Weimob resmi duyurusu:
Referans bağlantısı: https://tech.sina.com.cn/i/2020-03-01/doc-iimxxstf5622524.shtml https://mp.weixin.qq.com/s/a1EGF0CJT0Nwiy4A4HsIOg
- Bitiş -
Qubit QbitAI · Toutiao İmzalı
Bize dikkat edin ve en son teknolojiden haberdar olun
