システムを外注し、社内にいじれるエンジニアがいない時のリスクヘッジってどうしたら・・・？

Question

私はいわゆるフロントエンドエンジニアです。マークアップエンジニア、コーダー、ウェブデザイナーとかいう種類の人間です。

このたび自社サービスをローンチしまして、ものすごい勢いで会員さんが増えていてとってもありがたいんですが、本日原因不明のトラブルに見舞われました。

サーバがダウンしたのか突然ページが表示されなくなってしまい、社内はパニック！

そこですぐにシステムを外注した会社さんに連絡を入れ、サーバを再起動してもらいなんとかすぐに元に戻りました。

このときふと思ったのですが、この会社さんは例に漏れず、とっても忙しくてなかなかリソースを確保しにくい時が多々あります。
今回はたまたま空いていたのですぐに対応してもらえましたが、どうしても無理な時が今後絶対出てきそうなのです。

しかも、当社では大規模なサービスを作ったのが今回が初めてなので、何が起こるのか予想ができません。（今まではヘボいレンタルサーバでMTやWPを作ったりする程度でしたのでその知識レベルです）
サーバはIDCFを利用してて、これまた全く知識がありません。
MySQLもターミナルもよくわかりません。勉強しても脳が拒絶するようになっているようです。

そこで皆さんに聞きたいのですが、このような場合どのようにリスクヘッジするべきなのでしょう？
突然サーバが「長時間」止まったりしたらすごい数のお客様に迷惑がかかってしまいます。
致命的なバグでお客様・エンドユーザーに不利益を被ることになっても大変です。

微妙な質問で申し訳ないのですが、いろんなご意見お待ちしています。

補足：安く相談に乗るよという方もいたらうれしいです。

Answer 1

今回のダウンも原因不明では、いつ再発するか分からないので原因究明が必要だと思いますし
開発会社と保守契約を結んで面倒みてもらうのが1番かと思います。

Answer 2

基本設計書、詳細設計書、運用設計書、運用マニュアル、その他パラメータシート等は納品してもらっているのでしょうか？

Comments

[1000]

基本設計書・詳細設計書的とはサーバサイドのプログラム的なものでしょうか？だとすればとくにいただいてません。ただページ上の動きや機能の仕様書的なものは私が全部書きました。
運用設計書というのはよくわからないです。運用マニュアルはなく、さわって覚えた形で、疑問点があれば都度質問を投げてます。
その他パラメータシートなどがあれば、ある程度私のほうでも簡単な修正（たとえば検索結果の表示件数を変える程度）ならできると思うんですが、いただいてません。
実際短納期＆準備不足の案件だった（納期はかなーり伸ばしましたが）ので、これ以上あまりムリも言いづらいんですが、パラメータシートくらいは請求しても良いものですかね？

[laulaula]

私はインフラエンジニアですので以下インフラ観点になりますが、業務AP系でも概ね同じだと思います。

基本設計書は要件定義で固まった顧客側の要求された機能をどう実現するか記載する設計書です。
詳細設計書は基本設計書にそって、具体的なシステムの構成、設定値
(通常、デフォルト値と実際の設定値の並記)などが記載されており、極論、詳細設計書に記載されたパラメータを利用すれば同じシステムが構築できます。
また、障害発生時にも詳細設計書を確認し設定値を確認したりもします。

運用設計書は構築したシステムについて、人を軸にした運用方法について記載されています。基本はITILベースになるかと思いまうが、監視時の人の動き、障害対応時の対応フロー、インシデントの管理方法、問題管理(恒久対処の検討など)、変更管理(通常、緊急時のシステム変更承認プロセス、履歴管理等)、リリース管理(パッチリリースやシステム更改など管理)、予防保守(公開されたシステム不具合のパッチ情報の収集や適用計画)、構成管理(ドキュメントの種類・管理方法、資産・資材(ファシリティ)管理、システム構成要素の管理など)、アカウント管理、サービスカタログ管理、サービスレベル管理(SLA：サービスレベルアグリーメント：ユーザとコミットした可用性等（例：サーバダウン時は８H以内に復旧させる)）、、、etc。と継続的にサービスを運用する上な必要な設計書です。こういったものがなく運用されていると対応がお粗末になりやすく、想定外の事象が発生した場合に責任の所在が不明だったり、連絡フロー、承認フローが明確でないために対応が遅れたりします。

その他パラメータシートですが（表現も微妙なものも含まれてますが）、JOB構成やJOBスケジュール、バックアップスケジュール、バックアップ運用方式(詳細設計かな)、IPアドレス・ホスト名一覧、ユーザ名・パスワード一覧、メッセージ一覧、ディスク構成表、フロア図、ラック図、システム間連携図、ファイル転送、NW構成図(論理・物理)などいろいろありますが、システムによって違うので開発側に確認してみた方が良いかと思います。

通常、基本設計書、詳細設計書を作成してから構築作業を行うので、開発側でもっているかもしれません。
また、運用マニュアルですが、運用マニュアルとまではいかずとも、過去の対応手順を纏めた手順書等を開発側でもっているかもしれません。

[laulaula]

追記ですが、私の感覚で各種設計書が納品されないのは理解しかねるところです。

契約書の内容にもよるのでしょうが、数年と長いスパンで利用することを想定しているならなおさらです。

運用時の大きなリスクヘッジ。
それは、属人化とブラックボックス化であり、それを避ける意味でも設計書類は、極力納品してもらうことをおすすめします。

仮にですが、その保守契約を結んでいる企業がいきなり倒産し連絡が取れなくなった場合、そのシステムの維持は可能ですか？

また、以下私の私見ですが、
インシデント管理を確実に行い、過去の対応履歴や変更履歴を収集・管理・蓄積し、適宜見直し分析等を行い場合によっては是正し、または過去履歴の傾向より想定されるリスクを事前に予防を行うことがシステムの安定稼働には重要です。

過去の対応履歴よりシステム停止が大きな問題になっていれば、クラスタやLBによるn対m構成などによるシステムの冗長を検討すればよいなど、過去の情報を蓄積し運用する仕組みも重要です。

Answer 3

スモールスタートでサービス提供されたようですね。

事象から既にスモールではなくなってきてますので、事業計画の転換時期に入ってると思います。

そもそも設計見直しが必要であれば、再構築にかかるイニシャルコストと、サービスを安定稼働するためのマネジメントコストも事業計画に組み込む必要があります。

当然、開発ベンダーを交えて交渉していくことになるかと思います。

マネジメントコストについては、ITサービスマネジメント、ITILあたりの単語で検索してみると事例など含めた業務タスクが可視化されてますので、それをベースに保守ベンダーと詰めていくことになるかと思います。

Comments

[kurosawa]

サイト見ました。結構、大きなシステムですね。
クライアントさんがいるので 24/365の監視とサポートは必要かと思いました。
（即リカバリが求められるでしょうから・・・）

他の方もコメントしておりましたが、まずは監視系を組み込んでアラートで検知。
その後、暫定処理の流れになるのかと思います。

私なら、（寝れなくなりそうですが）
zabbixを導入して、閾値設定して、携帯にメールします。
まずは、このぐらいから始めてみる感じですかね。

Zabbixは、異常時のサーバリソース状態を履歴として参照できるので
障害の原因追求の根拠としても有効に利用できるかと思います。

しかし、PHPなのにサーバ再起動で解消する。つーところが結構引っかかりますが・・・

[1000]

ありがとうございます。
PHPでサーバ再起動で復旧するのは珍しい事象なのですかね？

[kurosawa]

珍しいということではありませんが、Java/Tomではリソース不足・環境設定とか設定の問題が多いのですが、PHPでは無限ループ、DBコネクション枯渇による待ち、APCなどのキャッシュ不具合などとシステムの品質に原因があることが多いと感じます。

原因は多岐に渡るので、不具合の特定と修正が大変かと。

まずは、なにが原因でサーバが応答しなくなり、それはどうすれば解消できるのか？をあらっていくしかないですね。

Answer 4

これは、お金で解決できる問題です。
0. 監視・保守・運用サポート契約
0. システムの冗長化
0. システムのバックアップ
などなど。
当然、稼働率を高く設定すればするほど高額な費用がかかります。
そのため、まずは、このシステムに対する稼働率の要件を社内で取りまとめることが必要です。
例えば、

• 稼働停止した場合は必ず２４時間以内に復旧させる
• ２４時間３６５日どんなことがあっても絶対に稼働停止してはならない
• 月に１回のシステムメンテナンス時だけ稼働停止を許す

などなど。

Answer 5

止まって困るサービスなら、24時間365日の監視および運用体制が必要です。想定される障害に対してどういう対応をするか事前に決めておいて、その対応を行う。
監視と言っても人間が張り付いて画面を見てると言うよりは障害を自動検知してアラートメールを飛ばし、そのメールを受けて対応を始めるということでも良いかと思います。特定の障害については対応自動化も可能でしょう。

しかも、当社では大規模なサービスを作ったのが今回が初めてなので、何が起こるのか予想ができません。

ということであれば、どういう障害を想定するかのコンサルテーションを頼むところから始めるのでしょうか。

プログラムバグの修正まで24時間365日の待機体制というのは難しい（現実的でない）でしょうし、即座に修正が出来る物でもないので、原因がプログラムバグである場合に備えて、暫定対応策（サービスの縮退など）も決めておく必要があります。

Answer 6

私も、他の方々と同じく開発会社と保守契約を結ぶことが一番だと思いますが懸念点があります。
それは開発会社との「コミュニケーション」です。

・トラブルは解決したが原因は不明
・開発に関する設計書類の提出なし
・保守契約の提案なし

以上から感じ取れるのは開発会社とのコミュニケーション不足です。
率直に現在の不安を先方に相談し、次善の策を提案してもらうのが近道ではないかと思います。
これまでの経緯からお互い言いづらいこともあるかもしれませんが、
ここは相互理解を深める必要があるのではないでしょうか？
これがないと保守契約を結んでも効果があまりありません。

他の方が提案している対応方法は正しいですがすべてコストと知識が必要になります。

・24時間/365日の監視体制は週の通常勤務時間が40時間だとすると、4人以上必要な計算になります。
・冗長化は構成の構築だけでは不十分で緊急(リカバリ)時に対応する人員も確保しなければいけません。
・外注にしろエンジニアを雇うにしろシステム構成が説明できないと十分に活躍できません。

ここらへんの事情がよくわかってないと保守は円滑に進みません。

また、「リスクヘッジ」とは何が「リスク」なのでしょうか？
ご自身が不安に感じていることはご自身が詳細にシミュレートし、
サービスのあるべき姿を作るべきではないかと思います。
「事業計画の転換」なる言葉も出てきましたが、
現在のサービスを立ち上げたときもあらかじめイメージがあり、
それを具体化したのが今の状態だと思います。
これをさらに発展させていくべきです。

最初からまともに動くシステムのほうがむしろまれで、
大体はトラブル経験からノウハウを蓄積していきますので、
まずは落ち着いて課題を上げていき、一つづつ解決していくしかないのではないでしょうか。

ちなみにサーバ再起動も週に1回程度、システムの負荷がもっとも低い時間帯に定期的にやると
だいぶ安定感が違います。やり方を開発会社に聞いて、ご自身でやられてみてはいかがですか？

Answer 7

サーバー側のエンジニアの立場からなのですが、
お金をかけてサーバーの冗長化を行うことをおすすめします。
また、自社内にサーバー側のエンジニアを雇い、データセンターを借り、
サーバーを複数台確保することができれば、なお良いと思います。

事象から既にスモールではなくなってきてますので、事業計画の転換時期に入ってると思います。

この通りだと思います。
このままスモールサービスのままでいくつもりでないのなら、
自社内でノウハウの囲い込みや人員の確保を進めたほうがいいと思います。

Answer 8

サーバー屋やってるものとしては、お金をかけて専属のエンジニアを入れるべきですね。
というのも、自社である程度解決できないと、今後、委託出来ない法律が、間もなく可決される見通しです。
再委託は原則禁止になる法案だったりするのを、ちょっと国会議員に陳情して、法案にまとめ、今国会に提出されています。
ちょうどいい機会かと思いますよ。
マイナンバー法の関係で、セキュリティ対策が義務になり、委託先がヘマした時の責任は、全て委託元が負う事になるだけに。

Answer 9

社内SEやっているものです。
社内サーバーやらと、業務システム開発を主にしていますので、諸々知識かったよっているかもしれません。

＞この会社さんは例に漏れず、とっても忙しくてなかなかリソースを確保しにくい時が多々あります。
まずはこの点を保守契約などで、明確に対応とってもらえるようにすべきと思います。
当然、お金のかかることですが、会社内にそれができる方がいないのであれば、その点も外注するしかありません。お客様へ迷惑をかけるリスクを回避するために必要な費用だと思います。

＞原因不明のトラブル
これを原因不明のまま、ということは対策もとれません。
再発するリスクを残したまま、運用することになります。ですので、

１）発生してもサービスを継続して提供できるようにする。
冗長化とか、負荷分散、とか。

２）原因を追究して、原因を解消する。
バグなら修正する、過負荷なら耐えられる環境へシフトする、とか。

物理的なハードになると、冗長化やら負荷分散やらはコストがすごかったり、どこまでの負荷を見積もれば良いのか？は成長中のサービスでは難しいです。

そこで、会社の方針としてデータを外部へ預けれる（という表現でよいのか）のであれば、
AWSとかAzureとか、クラウドサービスも選択肢かと思います。
「増やしたいときに、リソース増やせる」のが利点だと思いますので。

できれば、今回の対応などで、ある程度の知識などを仕入れて社内で共有できると良いと思います。
自分ですべて作業できなくても、仕組みや概要をできるだけ捉えるだけでもOKです。
全部外部へおまかせ、となるとどうしても余計なもの（コスト）がくっついてきます・・・
それを見分けて、うまく外部を使えるとコストが抑えられたりします。

Answer 10

ノンストップＳＹＳＴＥＭであれば、ＣＰが無いのはＮＧです。
サーバーやネットワークのシングル構成？も同様にＮＧです。
また、ＨＡやレプリカの構築するのも昔からスタンダードです。
今からでも遅くないので、ＣＰ、ＢＣＰを決めて予算取りして、冗長構成を構築されたら良いと思います。
当面は閾値の監視等で凌ぐしかないでしょうが

ひざを突き合わせてのお話しであれば最善案のアドバイスが可能でしょうが．．．
詳しい事は分らないので的確な事は言えませんので取り敢えず
最低限、下記のⅠ～Ⅲの対応は計画するべきです。
ましてやノンストップシステムのサービスであれば尚更です。

Ⅰ．ハードウェア
①物理的に形のある物は必ず経年劣化し故障します。
②ＥＯＳ対応

Ⅱ．ソフトウェア
①バージョンアップに伴う障害
パッチ適応などバージョンアップを実施するとソフトウェアやドライバの相性により不具合が発生する事が多々あります。
②ＥＯＳ対応

Ⅲ．その他の障害
①人災による障害
②天災による障害
③ｅｔｃ．．．

最低限、二重化は必須です。
リスクヘッジするのであれば、日時でアクセス量等の統計データを取得し、損出を纏めるのが宜しいかと思料致します。
例えば、保守料とサービス停止に伴う損出を天秤にかけて、どちらが良いかといったメリット、デメリット明確して勘案していく事かと

余談ですが、私が体験した大きな障害では
１．阪神・淡路大震災
建物崩壊により機器崩壊
→移転場所の決定からの作業で１週間かかりました。

２．サーバールームのエアコンを間違ってＯＦＦして帰宅（お客様が）
オーバーヒートにより、サーバー停止、再起動を何度も繰り返しマザーボードが故障
→復旧に２日かかりました。

３．某アンチウィルスソフト会社の．．．
その当時、未だ殆どの会社では厳密にルール化されおらず、
ＰＣ使用者が勝手にバージョンアップやパターンファイルの更新した際に、正常起動しない現象が発生
→代替えＰＣの無い人は、再インストールからの復旧で半日以上かかりました。

４．電力会社の送電線を某工事会社が誤って断線
ＵＰＳを設置してあるシステムは正常にシャットダウンされ、復旧後に正常起動しましたが、
そうでないシステムの大半が正常起動せずハードが壊れたマシンも少なくはありませんでした。
→復旧に１時間～半日かかりました。

ＢＣＰ・・・事業継続計画
ＣＰ・・・緊急時対応計画
ＥＯＳ・・・End of Servics / End of Support
ＨＡ・・・高可用性
ＵＰＳ・・・無停電電源装置

Answer 11

いや！学ぶ絶好のチャンスですから自分で全てやり遂げるべきです。
スキルはこういう時に伸びます。一度外注するとブラックボックスをますます増やしてしまいます。
今は踏ん張って！これを経ると必ず組織のキャパが上昇します。

自分は全部自分で対応していたため、全ての経験を手に入れました。
これやってよかったと感じています。そうすると次に起きた時にそこまではいけるんです。
原因がわかると、案外簡単なことだったりしますよ！がんばってね。

Answer 12

サイト見ました。
4人いるわけですから、誰か勉強したらどうでしょうか。
本はところせましにありますから。
サーバー立てて、mysqlとphpを入れてある程度勉強するしかないかと
人を雇うのも手だと思いますが、ぜんぜんわからないとこの人ができるのかどうか
わからないのではないでしょうか。

これからどういう感じで会社を発展させていこうと考えているのかわかりませんが、
社内エンジニアがだれもいないというのは不安だと思います

Answer 13

再起動で復旧できるのであれば、開発元に再起動のためのマニュアルを作成してもらうのも良いかと思います。

再起動だけでは復旧しきれない場合を考えると、それに応じて外部の会社に保守を依頼する方法も考えられます。この場合、どの程度のダウンタイムまで許容するかに応じて、SLA(Service Level Agreement)の内容が変わってきますので、それによって費用が異なってきます。
例えば
・コスト高：24時間365日体制で監視してシステムダウンから何時間(or 分)以内に復旧する
・コスト中：システムダウンに気づいた時点で依頼して、依頼から何時間以内に復旧する
・コスト低：依頼から何時間以内に初回回答(復旧までの見通し)を報告してもらう
など。
というふうな松竹梅プランでどこかの保守会社に見積もりを取ってみて、一度ご予算と相談するのも良いかと思います。

また、以下の様に人工知能(AI)を使って運用監視と復旧の自動化を行っているサービスもあるので、ご検討されてみてはいかがでしょうか。(このサービスに関係する者ではありませんので、あくまでご参考としてご検討下さい。)
http://it-trend.jp/server_application_management/5065

Answer 14

現在は社内SEをやっておるものです。
現状、保守契約を結んでおられないようですので、社内SEで対応したいということですね。

もっとも容易で、早く、対応できるのは、保守契約の締結のように思います。
ただし、お金がかかります(簡単、早い、高い)。

また『再起動により復旧』という対応方法、『原因不明』という報告、ですが、少し不安が残ります。
業務復旧を最優先したのかもしれません。
ご対応いただいたベンダの対応者が、サーバインフラエンジニアではなく、プログラマの方だったのかもしれません。
この場合も保守契約できっちりと契約書に明記する必要があります(専任のエンジニアによるnn分以内の一時対応...など)。

以上は、現在の不安な状況への対策です。

以降は、わたしの実際にあった経験です。
わたしは、もともと(10年前)は、データベースエンジニアで、サーバOSには Unix を使っていました。
9年前(現在の会社へ転職して、1年後)のある日突然、インターネット系のサーバインフラエンジニアが全員辞めてしまいました。引き継ぎもありません。
Unix に精通したエンジニアはわたしのみでしたので、インターネットサーバ(WEBサーバ、DNSサーバ、メールサーバ)をすべて保守することになりました。正直パニックでした。
不安な気持ちのまま、日々、sshでログインし、コンフィギュレーションを調べました。
サーバのクラッシュ(ディスク故障)に見舞われたこともあります。
いまは、インターネットサーバ(WEB、DNS、メール)も全機、ゼロから(サーバOSインストールから)作り直しました。
わたしのポリシーとして、サーバは必ず冗長化します(データベースサーバは、RAID + レプリケーション + 遠隔地バックアップ採取)。
もともと、データベースエンジニアとして、技術者の一生を全うしようと考えていた(早すぎるのですが)のですが、すごく幅が広がりました。
いまは、よほどのことは自分(自前)で対処できます(ベンダ保守費は不要になります)。
1000さん、これは千載一遇のチャンスかもしれません。

Answer 15

開発した会社が保守契約の提案を出して来ないのが不思議です。
保守運用の提案を何社かに頼んでコンペにすれば、安くて良いのが出てくると思いますよ。
出来る事ならば、うちの会社もそのコンペに参加させて欲しいくらいです。

Answer 16

社内にエンジニアがいない会社に放り込まれたエンジニアが通ります(-_-;

SEやインフラエンジニアを雇ってシステム開発や保守のチームを作るのが理想ですが、これはこれで人件費がかかります。手っ取り早いのは外注先と業務委託契約をしっかり結んで、有事にすぐ対応してもらえる体制を作ってもらうことですかね。まあこれはこれでお金がかかりますが、規模によっては人件費より少なくて済みます。
それでも最低一人は、その辺のことが分かる人間がいるとよいです。でないと外注先にぼったくられますから(笑)

Answer 17

すでにいろいろな回答が出されていますが、
どれを採用するかは御社の事業計画によります。

さしあたり保守契約を結ぶ、
外注へ丸投げするのが一番手間は掛かりません。
しかし保守のコストは掛かるでしょう。
サービスが増えてくると無視できません。

今回の単発で終わらず、事業拡大していくのであれば、
設計書などのドキュメントを提出させてそれを読んだり、
サーバの冗長化をはかったり、データセンターを借りたり、
それらに対応するためインフラエンジニアを採用するなど、
自社内部で対応すると（スケールが大きければ）コストは節約できます。

たとえていうと、車に乗る回数が少なければタクシーのほうが安いし、
毎日乗るなら自家用車（オンプレミス）を持つほうが安くなります。
またその中間ではカーシェアリング（クラウド）が有効かもしれません。

今回の事件がきっかけになって、社内的に
それらの必要性を説得しやすいと思います。

（蛇足ですが、説得に失敗した場合、もしかすると、
ご質問者様がMySQLとかいろいろひっくるめた
インフラ回りも全部やらされる羽目になるかもしれません……）

Answer 18

通常、開発した所が保守契約に基づいて対応しますね。