開発とインフラのコミニュケーションエラー - 叡智の三猿

叡智の三猿

〜森羅万象を情報セキュリティで捉える

当サイトは、アフィリエイト広告を使用しています。

開発とインフラのコミニュケーションエラー

システム構築の要件は「機能要件」と「非機能要件」に大別されます。

機能要件は、システムが何をするべきか、どのような機能を提供するべきかを記述します。通常はシステムの利用者が要求を提示し、SEが要求を設計書に落とします。

非機能要件は、システムの動作の特性や制約を定義します。システムの性能、信頼性、セキュリティ、可用性、保守性などです。

非機能要件は、利用者が要求を提示することもありますが、対象範囲が広く、何が正解かを出すのが難しい要件です。多くは、利用者が機能要件を実現するうえで、エンジニアが制約事項を提示するケースが多いと思います。

開発プロジェクトでは、機能要件を定義するエンジニアと、非機能要件を定義するエンジニアは分かれます。

機能要件を定義するエンジニアは、開発エンジニアと呼ばれ、非機能要件はインフラエンジニアと言われるのが一般的です。プロジェクトのチームも分かれてます。

この区分けは、1980年代に定義されたISOによる「OSI参照モデル」の7階層がベースとなっています。ただ、今日では、TCP/IPが事実上の標準として広く普及してます(下図)。TCP/IPを基準にすると、第1層から第3層までがインフラの領域。第4層が開発の領域に当てはまります。

OSI参照モデル

ただ、開発とインフラは、コミニュケーションが上手く取れないことがしばしばあります。

両者のコミニュケーションエラーが引き金となり、システム障害に発展することもあります。

以前、常駐してた客先で、いつも会計システムが日中に落ちてしまう障害がありました。

開発エンジニアは、データを検索する際の絞り込み条件が緩く、利用者が大量データを検索することで、システムのリソースを消費していることで落ちているんだろうと指摘しました。

そのため、システムの検索条件を縛り、OR 条件による検索機能を廃止する改修をしました。

しかし、落ちる事象は続きました。

会計システムの特性上、月初は高稼働になるのですが、そういう大事なタイミングでシステムが落ちます。

利用者のストレスはMAXに達しました。

実はこの障害、データ検索の機能要件による問題ではありませんでした。

夜間のデータバックアップが時間内に終わらず、日中になってもバックアップを続けていたのです。

この客先では毎日フルバックアップをとっているのですが、会計データが蓄積したことでバックアップに時間がかかってしまったのです。

バックアップの方式は、非機能要件のひとつです。

開発とインフラの意思疎通が出来ていたら、無駄に障害を引き延ばさずに済んだことでしょう。

データバックアップは、フルバックアップ、差分バックアップ、増分バックアップがあります。

フルバックアップ

フルバックアップは、ある時点でのデータを丸ごとバックアップする方法です。丸ごとデータを取るので確実なバックアップ方法です。しかし、はじめはデータ量は少なくとも、次第にデータ量は増加します。それにより、バックアップの時間がかかります。ストレージ占有量も次第に増えます。時間と資源の大きい非効率なバックアップです。

フルバックアップ
差分バックアップ

差分バックアップは、ある時点のフルバックアップと比較して、変更した部分を保存するバックアップです。変更した部分だけを保存するので、フルバックアップのような時間も掛からず、ストレージ占有量が抑えられます。しかし、フルバックアップとの差分を取得することから、時間の経過と共に、バックアップデータ量が増えます。そのため、定期的にフルバックアップを取り、時点を新しくする必要があります。

差分バックアップ
増分バックアップ

増分バックアップは、前回から変更されたデータのみをバックアップする方法です。前回との比較で保存するので、差分バックアップのように時間の経過によってバックデータ量が増えることはありません。ストレージ占有量も抑えることが出来ます。しかし、復元は、最後のフルバックアップとそれ以降のすべての増分バックアップから再構成する必要があります。復旧に時間がかかるバックアップです。

増分バックアップ

定期的にバックアップを取得することで、BCP対策になります。

また、ランサムウェア攻撃を受け、身代金を要求されてもバックアップがあれば、暗号化されたデータを元に戻すことが可能です。

開発とインフラのコミュニケーションがうまくいかないと、プロジェクト全体に悪影響を及ぼします。両者が互いの役割を理解し、共通の目標に向けて協力する姿勢が大切です。