サーバー運用の運用において最重要なものにバックアップ運用があります。

システム構築をする時に要件定義を行いますが、システムが提供するサービスの要件ではなく、システムを維持するための要件を定義することを「非機能要件定義」って言います。

バックアップ要件の定義はこの非機能要件定義に含まれていて、主にサーバーエンジニアがお客さんと話を詰めることになると思います。

以下のようなことを良く話します。

• いつバックアップを取得するか
• 何世代保存しておくか
• どういう媒体に保存しておくか
• バックアップ媒体はどこに置いておくか

しかしちょっと運用に慣れてきて、実際の障害にも遭って、障害対応でリカバリの経験ができると、リカバリあってのバックアップよな、ということが分かってきます。

そうすると以下のようなことも非機能要件定義で必要だということも分かってきます。

• リカバリにはどのくらいの時間をかけて良いのか
• どんな障害を想定するか

これらを気にするようになる頃には、バックアップ/リカバリの手法、どんな技術があるのかに興味が向く頃で、色々勉強しますね。

単なるコピー・差分・リアルタイムのレプリケーション・etc.

少しコスト/パフォーマンスのことも気にするようになってくるでしょうか。


ですが、この頃に気に留めて欲しいことがあります。

テクニックに溺れてはいけません

バックアップ/リカバリのテクニックはそこそこ難しくて、サーバーエンジニアとしては珍しく勉強した甲斐が出るところ、外的な評価を受けやすいものです。

サーバーエンジニアとしては成長を感じる頃でそれは良いのですが、ここで大事な事を忘れてしまうのですね。

大事なのはサービスの滞りない提供であり、バックアップ/リカバリはその1手段でしかありません。

技術を手に入れると使いたくなるのが人情で、習い覚えたバックアップ手法を組み込む事に注力しがちになってしまうのもわかります。

でも、そういう時だからこそ「滞り無いサービス提供」という大原則にたち戻って見て下さい。

それでまたサーバーエンジニアとして一皮むけると思います。


バックアップの非機能要件定義のとき、特にデータベースのバックアップ要件、そしてリカバリ設計をするときには、こんな質問をお客さんにしてみて下さい。

例えば朝10：00の状態にデータがキッチリ戻ったとして、業務やサービスに問題は出ませんか？

このたった1行の質問の中に、矛盾があるように見えますね。

様々なテクニックを駆使してデータは「キッチリと戻っている」のです。

だけど業務やサービスに問題が出るとはどういうことか。

変化していくデータには連続性や順番のあるものが多く、ある時点の状態に完全に戻ったとしても、データの変遷がどこまで進行しているかが把握されていないと意味がないんですね。

どこまでデータ入力をしたか、お客さんが別途ノートに時刻付きで書いていれば良いのでしょうが、コンピューターのシステムを使っているお客さんがそんな事をいている訳ありません。

では利用しているアプリケーションはそれを考慮した設計になっているか、業務的なデータの括りで連続性を担保するようにしているかと言えば、伝票単体での入力は担保する、DBのトランザクション程度のところまでは担保する、くらいがせいぜいのケースが殆どです。


こうなると、お客さんにはもっと突っ込んで聞かなければバックアップの運用設計などできない…ということが分かってきます。

私は「どこかのタイミングで日次業務としてのデータの静止点を設けることができますか？(昼休みは必ずログアウトしてね♥とか)」なんて言葉でお客さんによく聞いていました。

ここまでやって、本当の意味で勉強してきたことが生きてきます。

どれだけのバックアップ/リカバリソリューションを持っているかで、柔軟な設計ができるのですから。

見積で「高いな〜」ってお客に詰められても、論理的な説明ができるでしょうから苦しみが減るように思います。
(見積提示なんてどう転んでも苦しみですからネw)


バックアップという保険にどれだけの金をかけるかは、技術進歩とともにいつまでも正答が出ないもので、サーバーエンジニアの永遠の課題です。

サーバーエンジニアの力の見せ所でもありますね。