k-oguma/webops_policies.md

## webops_policies.md

      
    Raw
  

              webops_policies.md
            
          
    [WebOps] 問題調査方法や構築時の注意点と方針

お客様から「ウェブページが表示されない」と問い合わせがあった場合

調査の概要


必要な情報を得られるだけ得る

トレーサビリティは高めておく (事前準備も可能な限りしておく)


Web/Appおよびインフラ調査

以下詳細
ユーザから確認したいこと


基本ポリシー/前提

欲しい情報を正確に全て得られるとは限らないので注意する

出来る限り、人力やユーザからの情報頼りではないようにする
可能な範囲で自動でトレース情報を取得できるようにもしておく


姿勢


全て 可能であれば という形でご協力を要請する

問い合わせや報告をしてきてくれた時点で、ある程度の協力姿勢はあるはずだと押し付けてはいけない
質問や確認依頼は、必要最低限とする

ユーザの手間をなるべく減らす努力をする
以下の質問全てをユーザに求める方針ではないということ


確認事項


[確認1] 現象を確認したおおよその日時


[確認2] 事象確認

表示されないとはどのような状態か

真っ白な画面か、HTTP Status codeの表示があるエラーか
画面に何か表示されているか
認証が通っていない、もしくは404とかではないか


どのような処理の画面か (何をしていた時か)


[確認3][可能であれば] URL操作ができるものだったら以下

前提

appから呼び出すwebViewなどだと通常URL確認やURL直接アクセスができないので、これはしません
Webだったら可能


[確認3-1] 問題がおきたURL

一部なのか、全体なのか

Pathは何か(RESTであればMethodもわかる可能性がある), query があればそれも


[確認3-2] 例えば https://example.com/?trace=20180827-123456 など調査用paramを入れたものでアクセスしてもらう

paramはログ抽出で利用し、プログラム的には無意味なもの

ユーザに頼むならheader 付けるよりもquery stringの方が簡単


[やらないこと] Debug mode のappを渡す、通信解析を依頼するなどはしない


[確認4] 認証が入るものだった場合

ユーザの固有情報を確認をします

ID

OpenID connect やOAuth2などの認証基盤を通したものであれば、そのID
この際、Password情報は送ってこないように事前に伝えておく (念のため)


[確認5] 回線種別

LTE? Wi-Fi? (自宅? 公衆?), IPv6?, NGN? etc


[必要そうであれば][可能であれば] 以下は、ユーザの協力姿勢などに左右されます

上記までの結果から必要そうであれば以下も実施

G-IPなどの情報が得られるサーバを立て、そこにquery strings 付きのURLでアクセスしてもらい、情報を得る。 (トレーサビリティ向上、エビデンス確認目的)

e.g.) https://example.com/?get-info=20180827-123456
query のparamは無意味なもので、logの抽出に利用するため


<?php
        if (isset($_SERVER['REMOTE_ADDR']))
        {
          echo "接続元 = ".$_SERVER['REMOTE_ADDR']."<br/>".PHP_EOL;
        }

表示されたIPを教えてもらう

動的IPでも短期間であれば変わっていない可能性が高い


調査方法


基本

事前に得れた情報が多ければ、下記の調査で絞り込みが早いです
思い込みや先入観は一旦棄てておく

事実関係を確認していく


[App調査] 簡単にわかるものか、すでにエラーが検知されているものがあるか監視で確認, 把握しておく

たとえばNewRelicやAirbrake等の監視に出ているはずなので、確認しておく
自前でやるならfluentdでログ集約してエラー解析/統計基盤に投げる, などそういったもの
php, rubyなどであればphp-fpm やunicorn, railsなどでError, stacktraceを抽出
すでに認識しているエラーがあることもある


[Infra調査] ログ調査

事前確認で得られた情報で下記のログから絞り込むようにすれば高速にtraceが可能
Webサーバのアクセスログ で HTTP STATUS CODEと日時でgrep
監視システムの検知内容を確認

e.g) Datadog, NewRelic infrastructure, Mackerel, Nagios, Prometheus, etc..


サーバ側の問題である場合は、DBも (e.g, slow-query)
[Cloud Log as a Service] GCP なら Stackdriverも使える場合がある


[再現テスト] こちらの環境から得られた情報を元に再現テストを実施


補足

[理想] 将来的には人工知能/機械学習の対応を進め、人間は重要な判断や調査/対応に注力できるようにしていくことが望ましいと考えています


[補足] 調査以降


クリティカルな問題か確認


1, 2番で総合的に判断

1,2 の調査が全て終わらないと判断できないというわけではありません (途中でもクリティカルな問題の場合は緊急対応)


状況に合わせて関係各所に連絡


クリティカルではない問題 (固有問題や、再現率が低いもの、影響が少ないものなど)

チーム内FBのみ (インシデント管理, ナレッジ管理)


クリティカルな問題 (緊急性が高い、影響が大きい問題)

必要各所へ伝達 (事象, 緊急性, 影響範囲, 再現率, 対策案)

上長, 関係各部署 (当該app/web開発チーム, 運営, etc)


メンテインの判断や相談


対応
問題管理, 情報管理


再発防止、情報共有

社内から「Linux サーバを構築してほしい」と要望があった場合の注意点


用途の確認

環境はdev? test? staging? production?
それに合わせて変わるので、spec / TDI (Test driven infra) も変わる
用途に対するプロダクトの要件や仕様
Container? Instance? XaaS? などのITアーキテクトも変わる


納期の確認

迅速に用意できるようにしておくことが望ましい
納期に合わせて優先度を決める


どこまで求めているか, システム要件

OS, Middleware, 設定
よしなにやってほしいとかざっくりした感じなら、こちらで良い感じに建てる


何度もありそうな作業なら自動化する

理想的な基準

3回以上ありそうなら自動化
基本的にテストは作る,CIも

例えば、依頼者が自らすぐにコマンド一発で構築できるようにDevOps開発する


[必要であれば] 運用設計

特に重要度が高いProduction向け

必要最低限のITIL的な思想も持っておく

構成管理はどうするか
サービストランジションなど


チューニングもした方が良いか


監視システムから「Ping の反応がない」とアラートが来た場合の調査方法


監視システムの当該アラート情報の確認

監視対象のIP Addressなど確認
複数サーバなのか単体なのか, 特定のNW全体なのか、他に問題が検知されていないか
閾値が厳しすぎないか


ローカルからもpingやtracerouteを打ってみる

RTT, ロス率, 経路の確認


サーバログインの試行
サーバにログインできた場合

例えば現在の一般的なCloudであれば、基本的にNWは生きてる可能性があるので、監視システムも疑う

サーバログインの回線とサービス/監視側の回線が別の場合があるので注意

オペレーション用の裏回線がある場合
その場合は、そちらの回線のNICで故障が無いかから確認


コンテナであれば、hostのNWは生きているかnetnsは? など見て、コンテナだけの異常なら作り直し
ICMP echo type 0 とtype 8はFirewall/ACLで許可されているか (サーバ内外)


サーバログインできない場合

近いNW機器やサーバに入って対象のIP Adressに対してpingを打って反応を確認
コンソール接続できるなら、それでログインしてサーバのNetwork確認


NW側の問題が疑わしい場合

管轄内の環境

SW等でPacket capture による解析やシステムログでtraceして対応
Privaet Cloud等だったらそれに合わせた対応を行う


管轄外

調査を求める必要がある場合は、得られた情報を提示の上、確認を要請する

e.g.) Public Cloud 事業者, ISP, IX, etc