コラム

CTC教育サービス・ホーム　＞　コラム　＞　クラウド時代のサーバー運用入門　＞　第3回　クラウド時代の障害対応術 (年末年始スペシャル) 保守対応ローテーションは大丈夫ですか？

クラウド時代のサーバー運用入門

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第3回　クラウド時代の障害対応術 (年末年始スペシャル) 保守対応ローテーションは大丈夫ですか？ (濱田康貴) 2017年11月

暮れも押し迫り、皆様お風邪など召されていませんでしょうか？いつの時代も年末年始くらいはこたつでゆっくり過ごしたいものです。しかし、24時間365日安定稼働を求められるWEBインフラを支えるエンジニアたるもの、自宅から障害対応をしなければならないことも稀によくある話です。今回は年末年始スペシャルということで、保守対応ローテーションについて取り上げてみたいと思います。

年末年始、家庭やオフィスで大掃除をされることが多いかと思いますが、保守対応ローテーションを考えることは業務の棚卸し、ひいては業務の大掃除にも繋がるといえましょう。

年末年始、何をしなければならないか？

いきなり極論になってしまいますが、「オフィスが閉まっているから対応できませんでした」は非常に格好悪いです。しかし、年明けの通常営業で対応すればよい作業を年末年始に家から作業するのは非現実的ですし、何のための年末年始休暇かわかりません。ですので、業務内容に優先順位をつけるとすれば、以下のようになるでしょう。

業務内容	優先度 (例)
通常業務	年内に終わらせるか、優先度や緊急度の低いものは年明けに持ち越す。家に持ち帰らない。
障害対応	高。リモート対応であってもダウンタイムを最小限に。

大きくカテゴライズすると、通常業務と障害対応に二分することができます。上記の表のように、年末年始は障害対応を優先して行うべきです。さりとて通常業務をまったく行わなくてよいかと言えば、そうではありません。例えばこれくらいは最低限やっておきたいものです。

syslogメールチェック
リソース監視
その他予定作業

syslogメールチェックとリソース監視は、言わば障害予兆監視です。もちろんsyslogメールが飛んでくるということは、何かがおこってから、にはなりますが、誰よりも早く障害に気づくという意味では無駄ではありません。リソース監視も、例えばzabbixやmuninなどのグラフを1日1回でも確認することで、リソース異常に気づくことが可能です。その他予定作業にどんな業務があるかといえば

元旦の 00:00 に公開するサイトのリリース
OSやミドルウェア、ライブラリ等のアップデートによるOSやデーモンの再起動
うるう秒対応

などが挙げられます。過去のうるう秒挿入は1月1日と7月1日に行われていましたので、今年の年末年始がうるう秒挿入に該当するかどうかを確認しましょう(幸い、2018年1月1日にうるう秒が挿入されることはありません)。

参考URL : うるう秒実施日一覧 | 日本標準時グループ
( http://jjy.nict.go.jp/QandA/data/leapsec.html )

これまでに挙げた3つの業務「syslogメールチェック」「リソース監視」「その他予定作業」を滞りなく行うために、年内に以下の準備を行いましょう。

1. 自宅から必要なリソースにアクセスできることの確認

(ア) オフィス外からアクセスできない仕様であれば代替手段を講じる (責任者のタスク)

① メールやWEB、各種資料などのアクセス権確認

② 社外からアクセスさせないリソースの確認

1. 社外からのアクセスを許可しているメンバーの把握

2. 代替手段の確保

③ サーバーやネットワーク機器、VPN等のアカウントの確認

(イ) 自分が年末年始のローテーションに組み込まれているにもかかわらず、他のメンバーがアクセスできて自分「だけ」がアクセスできないリソースがないかを確認する(メンバー全員のタスク)

① メールやWEB、各種資料などにアクセスできることの確認

② サーバーやネットワーク機器、VPN等の接続確認

2. その他予定作業の事前準備

(ア) 作業計画作成 (責任者のタスク)

① 作業フロー(全体計画作成)

② 各作業項目における開始条件、終了条件の整理・可視化

③ 各作業項目において終了条件に合致しなかった場合のコンティンジェンシープラン作成

④ 異常終了時エスカレーションフロー作成

⑤ 異常終了時の影響範囲調査

⑥ 作業日時(借用時間)調整

⑦ メンバー、ステークホルダーの連絡先、連絡順位の整理・可視化

(イ) 作業計画の理解と手順の把握 (担当メンバー全員のタスク)

① リリース対象のファイルなどは年内に所定の場所へ保存する

② 開発環境などでリリースリハーサルを行う

年末年始に限らず、必要なリソースにアクセスできることの確認と事前準備は常に行うべきですが、リモート環境からでもオフィスにいるときと同じ品質で作業ができるかどうか、という観点でチェックする必要があります。また、どうしても社外からアクセスさせたくないリソースがある場合の代替手段、エスカレーションルールについても事前に計画しておくことがベストです。
特に、お客様やMSP事業者などとの調整が必要な場合は年内の早めのタイミングで調整しましょう。また、物理サーバーを保守している場合、ディスクなどの予備部材がどこにあるか、搬入搬出の手続きなどに支障が出ないかどうかもあわせて確認しておきましょう。

予定作業の事前準備、年内タスクの棚卸

前章でも触れましたが、年末年始の事前準備は

社外から必要なリソースにアクセスできることの確認
年内の営業日にできる作業は年内に終わらせ、リモート対応の工数を極力減らす

これら2つの観点で行います。私が所属していたチームでの実例を含め、いくつかのケースを紹介いたしますので、参考にしてみてください。

ケース1　kernelやglibcのアップデート

kernelやglibcのように、アップデート後にOSの再起動が必要
借用時間(再起動してもよい時間)は12/31 18:00～19:00

通常業務時間帯であれば、アップデートと再起動を一連の流れでやってもよいのですが、万が一パッケージのリポジトリに接続できなかった場合など、そこで業務が止まってしまいます。ですので、借用時間になってはじめて「さあアップデートしよう」というフローではなく、年内の営業日にあらかじめアップデートだけしておき、年末の借用時間は再起動のみ行う、という手順のほうが少なくとも「アップデートできなかった」というトラブルは起き得ません。再起動時のトラブル(シャットダウンできない、起動できない)の可能性はありますが、次の対応手順を用意しておくことで、トラブルを回避することができるはずです。

各手順の異常終了時におけるエスカレーションルールを確立する(担当者判断でやみくもに復旧させようとしないこと)
事前(年内の営業日)に同じパッチレベルの検証用マシンで全手順の通しリハーサルを行い、問題ないことを確認する
リモートコンソールやVNC、必要な場合はデータセンターへ入局して再起動を行う手順を作成し、メンバー全員に共有する
待機系マシンがあるのであれば、待機系マシンから作業を実施する

年末年始に限ったことではないですが、上席者やステークホルダーの不在時に障害が発生した場合、平日日中帯以上に障害が長期化しがちであることを考慮すると、最低限上記観点で作業計画をたてるべきでしょう。

ケース2　うるう秒対応

うるう秒対応も、年内の営業日内で実施できる対策は次の通りです。

ntpdまたはchronyのアップデート
tzdataのアップデート
glibcのアップデート
ntpdを-xオプションつきで起動(または再起動)し、slewモードで時刻同期させるようにする

などの対策があります(詳細については割愛します)。しかし、(よろしくないのは承知ですが)事情によりこれらのパッケージがアップデートされていないLinuxディストリビューションの場合、時刻同期にシビアな要件が求められないことが前提ですが、一時的にntpdを止めてしまい、うるう秒が過ぎたあと、つまり年明け最初の営業日にntpdを再起動する、という逃げの手を使ったこともありました。

参考URL : 2016 年 12 月 31日に追加される「うるう秒」について | redhat Customer Portal
( https://access.redhat.com/ja/node/2487881 )

年末年始保守対応ローテーションの組み方

さて、いよいよ年末年始保守対応ローテーションの組み方について述べてみたいと思います。最初に前提条件を箇条書きにしますと

年末年始にやるべき業務が整理できている
年末年始にやるべきではない業務が整理できている
年内に終わらせるべき業務
年始からの着手でよい業務
例外発生時またはリソース異常時のエスカレーションフローができている
エスカレーション基準
エスカレーション先 (可能であれば複数人)

そして、忘れてはならないのが

熟練者であっても新人であっても同じ作業をしなければならない
年末年始に新しい仕事を作るべきではない

という原則です。これらの条件をまとめると、年末年始保守対応の究極の目的は、メンバー全員で今あるサービスの現状維持ができることであると言えましょう。そして、そのサービスレベルは一番伸びしろの多いメンバーが基準になります。もし余力があれば、熟練者のローテーションと新人のローテーションを別に組んで、1日に必ず熟練者と新人の2人が体制に組み込まれているのがベストです。人数の関係上それが困難であるならば、何かしらの対応をする前に必ず熟練者へ連絡する、という手順になるでしょう。繰り返しになりますが、一番伸びしろの多いメンバーにrootを持たせることになりますので、充分にこれを意識してください。

忘れちゃいけない年始の振り返り

年末年始の保守対応が終わり、無事新年最初の営業日を迎えることができました。通常の営業体制をスタートさせるのも大事ですが、必ず関係者全員が集まり、年末年始保守対応の振り返りを実施してください。
何事もなく(障害が発生することなく)終わるのが一番ですが、あくまでこれは結果論です。単に障害件数をまとめたところで、それ自体は無意味ではないのですが、今後へ生かさなければ無意味になってしまいます。最低限

•　年末年始監視対応結果

▸　障害について(サマリー)

▸　性能異常、予兆について

•　障害発生まとめ

▸　発生箇所

▸　障害内容

▸　発生日

▸　収束日

▸　一次対応者

▸　二次対応者

▸　直接原因

▸　間接的原因

▸　暫定対処 (途中経過含む)

▸　恒久対処 (今後の予定も含む)

•　予定作業まとめ

▸　作業内容

▸　作業担当者

▸　作業結果

▸　今後のタスク

最低限このくらいはまとめておきたいものです。障害は発生しないことに越したことはありませんが、いっぽうでこうした状況で障害対応をするということは、手と頭を動かした人だけに経験値が積み上がるということでもあります。そして、これをチームに展開する(アウトプットする)ことで、自分の考えがまとまるというメリットもあります。

いかがでしたでしょうか。年末年始対応ひとつ取っても、これだけ考えることがあります。ひいては、通常業務においてもチームの業務フローを改善するひとつのキッカケにもなり得ますので、真剣に取り組む価値はあると言えましょう。次回をお楽しみに！