災害後、ウェイモブは独自のデータベースの構築を断念し、商人に1億5000万元を支払った。

[[316623]]

【51CTOオリジナル記事】

先週、WeMallは大規模なシステム障害に見舞われました。公式発表によると、WeMall研究開発センター運営保守部門のコア運営保守人員である彼は、2月23日夜18時56分に個人のVPNを通じて会社のイントラネットジャンプマシンにログインし、個人的な精神的および生活上の理由により、WeMallのオンライン生産環境に悪意を持って損害を与えました。これは運営保守部門のコア従業員が生産環境で「データベース削除」操作を行ったことが原因でした。

このデータベース削除事件はIT技術界で広く注目を集めており、編集者はネットユーザーが特に知りたいいくつかの疑問を整理した。なぜ運用と保守による被害がこれほど大きいのか？なぜ復旧にこんなに時間がかかるのでしょうか？ WeMall には経営上の抜け穴がありますか?同様の事故を防ぐにはどうすればよいでしょうか?この目的のために、編集者は、Wharton Onlineの責任者であるZhu Lei氏、Alibaba Cloud OLAP製品チームのシニア製品専門家であるHan Feng氏、業界で著名なソフトウェア開発エンジニアリング効率の専門家であるRu Bingsheng氏に独占インタビューを実施しました。その内容は次のように要約されています。

なぜ、たった一人の運用・保守担当者によって引き起こされる被害がこれほど大きいのでしょうか?

情報化時代において、孤立した個人は存在しない

情報化時代においては、システムの統合がますます高度化し、一人の人間がシステムを完全に破壊する可能性もあります。しかし、情報化時代以前には、これは想像もできなかったことです。人類の歴史において、個人が国家や王朝の歴史的方向性を決定することは珍しいことではありませんが、そのためには高い権力の地位にある大物でなければなりません。この事件の主人公は、会社の中核的な運用・保守要員として、当然ながらこうしたことに関しては有利な立場にある。

クラウドサービス、運用、保守の権限が広すぎる

運用と DevOps に関しては、多くの IT 運用担当者が権限を持ちすぎていて、システムや製品を破壊するほどの権限を持っていることがわかっています。これは一部のスタートアップでよく見られます。現在 Weimob が提供しているサービスはサーバー上に展開されています。作業を円滑にするために、運用および保守エンジニアには、サーバー上であらゆる操作を実行できる高い権限を持つアカウントが与えられます。例えば、今回のデータベース削除インシデントでは、運用保守エンジニアが高権限アカウントを使用してサーバー上のファイルを削除したため、サーバーが直接クラッシュし、会社の業務が中断されました。

避けられない人的要因

運用・保守担当者が悪意を持って自らのシステムを破壊するかどうかにかかわらず、人間のオペレーターとして、急いでミスを犯す可能性は依然としてかなり高いです。したがって、この問題が私たちにもたらす啓示は、個人がシステム内で果たす役割に十分な注意を払い、個人によって引き起こされるシステムの失敗を避けるために個人の行動を厳しく監視しなければならないということです。

回復にはなぜそんなに時間がかかるのでしょうか?

一般的に、データのバックアップでは、少なくとも 30 分以内に最新のデータを復元できるはずだと言われています。 WeMallはすでに問題の修復に全力を尽くしており、Tencent Cloudも技術支援を提供していると表明しているのに、なぜ完全な復旧にはこれほど時間がかかるのでしょうか?

影響要因1: 災害復旧の問題

運用保守担当者は本番サーバー上のファイルを削除し、バックアップサーバーを損傷したことについては言及しませんでした。 WeMall が高性能な災害復旧機能を備えている場合、技術的な観点からサービスの復旧はそれほど難しくありません。ただし、現在の公式情報によると、実稼働環境のローカル データベースでデータベースが不可逆的に削除されているはずなので、そうでなければそれほど時間はかからないはずです。ローカルの本番データベースが消失したと仮定すると、唯一の方法はリモート災害復旧フルバックアップデータベースを使用して復旧することですが、これによっても、リモートデータベースの容量が大きく、ネットワーク転送に多くの時間が必要になるなど、一連の問題が発生します。

要因2: 複雑な回復プロセス

データ復旧に関しては、緊急チームの対応速度、技術力、削除されたファイルのサイズ、ファイル削除後のハードディスクの頻繁な読み書きなど、多くの要因が影響します。これらのいずれかに問題があると、復旧時間に影響します。

影響要因3 :不完全な復旧計画

ビジネスがこのような大きな混乱に見舞われた場合、完全な復旧計画を立て、実際にリハーサルを行うことが非常に重要になります。事前の準備がなければ、問題発生時に迅速に対応したり、問題の範囲、復旧策、関連するリスク、必要なリソースなどを検討したりすることが難しくなります。慌てて対応すれば、どうしても一つのことに気を取られて別のことに目が行き届かず、復旧の程度や時間を見積もることが難しくなります。

影響要因4 ：技術的な実装の難しさ

運用や保守に詳しくない人は、復旧はシステムを再インストールしたり、データベースのバックアップを復元したりするだけなので、比較的簡単だと考えるかもしれません。しかし、実際には、関連する技術は私たちが考えるよりも複雑です。

1. ビジネス アーキテクチャが複雑です。一般的に使用されるソフトウェアのアーキテクチャと展開は非常に複雑です。今日のマイクロサービス時代では、各マイクロサービス自体がクラスターです。マイクロサービス間にはさまざまな依存関係があり、各マイクロサービスがデータベースを処理する場合があります。これらのサービス間の依存関係と構成を整理するだけでも、誰もが圧倒されるほどです。

2. 時間は限られており、課題は重い。この事件はほぼ全体のアーキテクチャの再編成を伴い、0から1に新しいシステムを構築するのと同じくらい困難です。顧客のプレッシャーと世論のプレッシャーも相まって、その困難さは想像に難くありません。

3. 増分バックアップの整合性の欠如により、データベースの問題が発生する可能性があります。また、最近のデータ スキーマの変更により、バックアップ データの互換性の問題が発生している可能性もあります。これらすべてには、研究開発担当者と運用・保守担当者の共同作業が必要であり、作業負荷の増加と時間の遅延につながります。

ワイモブの問題: 技術管理とデータ災害復旧は無視できない

コストは企業のデータ管理投資に直接影響を与える要因である

WeMallデータベース削除事件は、一部のインターネット企業の内部データ管理の混乱を露呈した。論理的に考えると、WeMall のような規模の企業は、データのセキュリティと保護に多額の投資を行い、細心の注意を払う必要があります。しかし、この事件の背後には利害関係の問題が隠れている。WeMallに代表される企業にとって、データのセキュリティと保護は比較的大きなコスト支出であり、直接収益を生み出すことはできない。そのため、まだ成長段階にある一部の企業は投資にあまり注意を払わず、制度的保護の多くは表面的なものにとどまっている。大企業の場合、データセキュリティを無視すると損失が大きくなる可能性があるため、一般的に大企業はデータセキュリティに対する投資と対策がより標準化されており、WeMallのデータベース削除のような問題は基本的に発生しません。

インターネット企業には社内管理能力が欠けている

21世紀はインターネットなどの新産業の時代ですが、経営問題は常に新興インターネット企業の発展にとって最大の障害となっています。企業経営の重要性は、おそらくすべての企業幹部が理解しており、どの企業のリーダーや舵取りも無視できない問題ですが、それを真に実現するのは本当に困難です。

インターネットは急速に発展していますが、同時に隠れた危険ももたらしています。業界の急速な発展により、インターネット企業の上級管理職は経営を学ぶ時間も、社内のスキルを向上させる時間もありません。WeMall事件はインターネット企業に重要な教訓を与え、より多くの企業がこの事件から学ぶことを願っています。

このような事故を避けるにはどうすればよいでしょうか?

この事件はWeMallとその顧客に多大な損失をもたらしました。事件全体の背後で明らかになった管理と技術の抜け穴に関して、他の企業、さらには業界全体はどのようにして同様の問題の再発を回避すべきでしょうか?編集者はRu Bingsheng氏とZhu Lei氏の提案を要約し、運用と保守、企業の観点から議論します。

運用・保守技術者向け:

1.手動操作やメンテナンスは避ける

現在、ソフトウェア アーキテクチャの複雑さが継続的に増大するにつれて、運用と保守の概念と技術的手段は、初期の「手動」運用と保守から現在の DevOps、そして新たに登場した AIOps へと、絶えず進化しています。しかし、人間の影響は常に存在してきました。

これは、大企業が、個々の単一障害点の無制限な拡大を避けるために、レイヤーごとの監視と承認を備えた、比較的完全な階層型およびレイヤー化されたリリース プロセスを確立する理由でもあります。もちろん、これらの監督と承認は、従来のリーダーシップの署名に頼るのではなく、テクノロジー主導の DevOps パイプラインに組み込む必要があります。

システム パラメータ、セキュリティ ポリシー、ネットワーク構成、アプリケーション パラメータ、環境パラメータ、ファイル更新、データベース更新など、運用環境へのすべての変更は、DevOps パイプラインを経由して正式なリリース プロセスを経る必要があります。すべての操作はスクリプトまたは自動化されたコードによって完了する必要があり、運用環境でコマンドを直接実行できる権限を個人に与えることはできません。

したがって、いかなる形態の手動操作およびメンテナンスも避けるべきであり、「人が直接マシンを管理する」のではなく、「人がコードを管理し、コードがマシンを管理する」という考え方を提唱すべきです。

2. 雨の日に備えて災害復旧訓練を実施する

一般的に、ToDo 項目は、重要かつ緊急なものと、非常に重要だが緊急ではないものの 2 つのカテゴリに分けられます。これらは、運用および保守担当者が頻繁に直面するさまざまな緊急対応タスク (運用環境のバグ修正、ホットフィックスのリリースなど) と予防的なタスク (自動化された運用と保守、監視データの分析と統計、モデルの取得と最適化など) です。

理想的には、雨の日の計画作業に多くの時間を費やし、消火作業に費やす時間を減らす必要があります。雨の日に備えての作業がしっかり行われていれば、消火活動の可能性は減ります。しかし、現実はまったく逆です。運用・保守担当者は日々、さまざまなリリースやオンラインの消火活動に忙しく、さまざまな時期に負っている技術的負債を返済するエネルギーがありません。このモデルはコストセンターになる運命から逃れられません。

そのため、運用保守部門は平時に定期的にいくつかの障害訓練を実施し、カオスエンジニアリングの考え方と組み合わせて、システムの堅牢性と保守性を確保し、さまざまな突然の「ブラックスワン」イベントに対処する必要があります。 「本から得た知識は浅い。本当に理解するには実践しなければならない。」実際に障害を体験してこそ、貴重な実体験をたくさん得ることができます。考えるだけではうまくいきません。

会社全体：

1. O&Mはコストセンターであるという誤解

多くの人の目には、運用保守部門はコストセンター、つまり単にお金を使う部門として分類されます。運用保守はコストセンターであるという宿命論は、実際には運用保守の発展にとって非常に有害です。運用保守部門が本番環境で機械的リリース実行と消火活動の状態に長期間いると、終わりのない悪循環に陥ります。

多くの場合、私たちは常に目に見える問題を解決しますが、目に見えない問題は目に見えない場所に集まる傾向があり、これらの問題が一度現れると大きな問題になります。そのため、運用・保守はコストセンターであるという考え方を変え、運用・保守担当者がシステム上の問題をより積極的に考え、解決できるようにする必要があります。

2. 危機対応広報をしっかり行う

WeMallによる今回のデータベース削除事件は、多くの業界のユーザーに多大な影響を与えましたが、この危機に直面してWeMallが示した社会的責任感は、私たちにとって参考になり、学ぶ価値があるものです。突然の障害に直面しても、WeMallは真実を隠そうとせず、すぐに公式ウェブサイトで声明を発表し、事件の背景にある理由を説明し、その後の復旧計画と具体的な時間ノードを明確に通知しました。

こうした危機に対処する最善の方法は、もっと誠実になり、陰謀を企むことを減らし、一緒に問題に取り組むことです。隠そうとして、隠せないときに嘘をつき、そして張宇が歌ったように「一つの嘘でもう一つの嘘を隠す」となれば、必然的にさらに深刻な危機に陥ることになる。危機の時に私たちが望むのは、世間の憶測を減らし、黒人の広報に抵抗し、すべての人の理解と支援を得るための公開情報です。

3.内なる強さを鍛える

疫病などの緊急事態に直面したとき、まずやるべきことは、社員に実態を知らせ、必要な広報活動を行うことです。従業員の視点から見ると、一般的にはそのような状況を理解しており、貢献する意欲があります。 2 つ目は、勤務やローテーションなど、適切な作業負荷評価と必要な人員配置を行うことです。最も重要な点は、責任者が現場にいて、従業員と責任を共有することです。一方では、迅速な対応と迅速な意思決定を促進し、他方では、従業員のストレスを軽減し、会社のビジネスの急速な発展につながります。

また、経営陣は技術的な作業（基本的な操作と保守を含む）の重要性を重視する必要があります。私たちはチームビルディングに重点を置き、戦闘準備の整った技術チームを構築します。人材の観点からは、「選抜、育成、採用、定着」という多面的な流れの中で会社の価値観を把握し、会社の価値観に真に共感し、貢献する意欲のある学生を選抜して活用し、不適格な人材を排除する必要があります。

最新ニュース

2020年2月25日、WeMallは、同社のオンライン生産環境とデータが従業員によって悪意を持って破壊され、同社のシステムサービスが利用できなくなったという発表を行った。数日間の「救出」の後、3月1日にWeMallは、すべてのデータが回復され、3月2日にシステムのオンライン訓練が行われ、復元されたデータは3月3日午前9時に正式にリリースされるとの新たな発表を行った。同時に、影響を受けた商店に対する補償計画も提示された。

報酬プラン

公開情報によると、WeMall には現在 1,600 を超えるチャネル エージェントと 300 万を超える登録販売者がいます。 WeMall の停止により、300 万の商店が事業を停止し、莫大な損失が発生する可能性がある。そのため、WeMallも加盟店補償計画を発表し、総額1億5000万人民元の補償規定を準備し、そのうちWeMallが1億人民元を負担し、経営陣が5000万人民元を負担することになった。

システム障害によって引き起こされるさまざまな損失に対応して、Weimob はさまざまな補償プランも策定しました。

現金給付プラン

システム利用不可により利益損失を被った加盟店に対して、Weimobは加盟店の限界貢献利益額に応じて補償します。具体的な計算式は次のとおりです。限界貢献利益額=平均日収入×業界平均限界貢献利益率×システム障害時間

交通補償プラン

システム利用不可によりトラフィック損失を被ったマーチャントに対して、WeMallはTencent Advertisingに5万回のトラフィック補償を提供し、アカウント運用サービスを提供するとともに、SaaSサービスの有効期限をさらに2か月延長します。

自社構築のデータベースを放棄し、インフラストラクチャをクラウドに移行する

上記は経済的な補償ですが、技術面では、今回のコア運用・保守によりWeMallの生産環境とデータに損害が発生し、商店主はWeMallシステムの安全性と安定性に疑問を抱くようになり、WeMall自体にも警鐘を鳴らしました。

WeMallは3月1日に発表した発表の中で、インフラの完全なクラウド移行をサポートし、自社構築のデータベースサービスを段階的に廃止してTencent Cloud Database（CDB）に移行し、データベースのクロスアベイラビリティゾーンとオフサイト災害復旧機能を強化し、同時にBlackstone 1.0物理マシンをBlackstone 2.0に完全にアップグレードし、クラウドホストを全面的に活用すると述べた。

さらに、WeMallはデータセキュリティ管理メカニズムとセキュリティ災害復旧システムの構築を強化することも発表した。

インタビュー対象者:

1. 汝矣生：業界ではソフトウェア品質と研究開発エンジニアリング効率の実践専門家として有名で、テンセントクラウドの最も貴重な専門家、中国商工会議所インターネット応用技術委員会のシンクタンク専門家、ベストセラー書籍『テストエンジニアのためのフルスタック技術の進歩と実践』の著者、『ソフトウェアテスト52講座-初心者から専門家まで実践方法』のコラムニスト。彼は現在、Dell EMC 中国 R&D グループのシニア アーキテクトです。eBay 中国 R&D センターのテスト インフラストラクチャのテクニカル リーダー、HP ソフトウェア 中国 R&D センターのシニア アーキテクトおよびパフォーマンス テストの専門家、Alcatel-Lucent のシニア テクニカル ディレクター、Cisco 中国 R&D センターのシニア エンジニアを務めてきました。ソフトウェア R&D と技術管理の分野で 16 年以上の経験があります。

2. 朱磊：運用と保守のセキュリティに重点を置く北京華東オンライン情報技術有限公司の創設者であり、『Dark War: The Battle for the Digital World』の著者。彼は以前、JD.com の R&D システム セキュリティ マネージャーを務めており、インターネット情報セキュリティ管理、豊富な情報セキュリティ概念、複数のセキュリティ システム アーキテクチャの経験において長年の経験を持っています。

3. Han Feng: ニックネーム: Qunfeng、Alibaba Cloud データベース製品チームのシニア製品エキスパート、CCIA (中国コンピュータ産業協会) のエグゼクティブ ディレクター、Oracle ACE、dbaplus コミュニティの共同設立者、ACMUG 幹部会および専門家グループのメンバー、「SQL 最適化のベスト プラクティス」の著者。

  [51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]