>>2006年02月28日SEに要求される力SEとして大成するには、どういう能力が必要か考えてみました。・新しいモノに興味があるか・新しい技術を使うべきところと、枯れた技術を使うべきところの見極めができるか・SE関連業務の勉強が苦にならないかほかに、こういった能力が必要というのがあれば、教えてください。最近の富豪的プログラミングに影響されてると、アルゴリズムを考えるのがおっくうになります。簡単に実装できるアルゴリズムを採用してしまいます。実装する前に少しだけ考えてください。そのアルゴリズムで本当に問題ないのか。大半の処理は性能に影響を与えません。一部の処理は確実に性能に影響を与えます。その一部の処理だけは、手を抜かずに考えましょう。実際に筆者がやらかした例を挙げてみます。メタデータを管理するクラスを作り、メタデータ自身をファイルで保管していました。データ量が膨大になるのは自明でしたので、データ自体の保存、読み込み処理は、当然、性能を意識して作成。テストは何事もなく過ぎ、リリースしてしばらくのこと。遅くて使えないと、顧客からクレームがきました。顧客環境を調査したところ、メタデータの検索で時間がかかっている模様。メタデータはたかだか100件程度だろうとタカをくくって、メタデータの探索は逐次探索としていました。実際の運用環境では10000件を超えており、一件のメタデータの探索に、平均10ミリ秒消費していました。いうことは、全件の処理は10ミリ秒×10000件=100秒となります。一回の処理に100秒かかるようでは、遅いといわれてもしょうがありません。メタデータだから、そんなに件数がないとサボった罰です。逐次探索からハッシュ探索に切り替えたところ、1秒かからずに処理が完了し、問題は解決しました。おかげで、顧客からイヤミを言われ、肩身の狭い思いをしましたとさ。気に入った方はこちらもクリック。障害報告書のフォーマット障害が起きたとき、なにが気分を重くするかっていうと、障害を顧客に伝える瞬間です。ハードウエア不良なら自分の責任は少ないのでまだマシですが、プログラムのバグで、しかも本番機でトラブルとなると、営業や上司に押し付けて逃亡したくなります。はいっても、技術的な話はSEに降ってくる宿命です。そこで、障害報告書だけ書いて、客への押しつけちゃいましょう。内容と対策を簡単に記します。顧客側の担当者は障害の詳細を知りたがりますが、上司や役員は概要だけで十分です。そこで、概要を説明し、詳しく知りたい人には後の部分を読んでもらうようにします。22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。サーバの再起動、およびデータベースに対する同時接続数の増加を行い、当面の現象は回避。不具合を対策したモジュールの入れ替えを2月20日に行います。障害の具体的な内容を記します。いつ、どこで、なにが、どのようになったかを客観的に説明します。21:50より、XXXサイトへのアクセスが通常の100倍に増加。22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。XXXサイトを構成するサーバX、サーバYを調査したところ、サーバXのデータベースにアクセスするプロセスがダウンしていました。障害の発生要因を記します。障害の原因と現象の関連が分かるように書きます。例:21:50より、XXXサイトへのアクセスが通常の100倍に増加。同時接続の増加により、データベースでの同時接続アクセス数を超過。データベースからエラーが返った時点で、エラーを想定しない処理となっていたため、サーバのプロセスがダウン(不良点)。サーバのプロセスがダウンしたため、XXXサイト全体の処理が停止し、無応答となりました。障害の対策を記します。対策には暫定対策と、本対策の2種類があります。暫定対策は、とりあえず現象を回避するための対策です。本体策は、障害の原因を取り除く対策です。例:サーバXを再起動し、関連プロセスを再起動することで、プロセスを復旧。同時にデータベースへの同時接続数を増やすことで障害の原因を暫定的に回避しました。このままでは、アクセスが増大した場合に、全ユーザのレスポンスが悪化します。原因を対策したモジュールを2月20日に入れ替えることで本対策とします。障害の対応経緯を記します。ユーザからのアクセスが通常時の100倍に増大。データベース接続プロセスがダウン。監視アプリケーションによりプロセスダウンを検知。御社オペレータに通知。御社オペレータより弊社に連絡。ログ採取後、サーバXの再起動を実施。データベースのログより同時接続数を超過した場合のエラー処理に問題があると判明。同時接続数の上限を変更。プログラムでの障害発生箇所を確認。同様の不良がないか見直しを実施。対策完了版への差し替え予定。予告どおり,障害対応の手順を説明します。第一報は,顧客か,監視ツールのエラーとしてあがってきます。そこで,何が発生しているのか,どのシステムに影響があるのか,現象を明確にし,他人に伝えれるようにまとめます。ユーザへの通知ユーザに障害の発生を通知します。障害があってもシステムには影響がなかったり,ダウン時間が短くユーザにバレないと考えたり,ユーザにバレても誤魔化せると踏んだ場合は,ユーザに通知しないこともありますが。障害情報の取得システムの挙動がおかしいときに,再起動するとそれなりの確率で直ります。勝手に再起動すると,障害が再現しないことがあり,原因不明で片付けられてしまいます。二度と発生しない障害ならいいのですが,この手の障害に限って保守部隊のいないスキを狙ったかのように発生します。そこで,保守部隊に確認して,再起動しても問題ないか,再起動する前に取得しておく情報がないか,先に確認しておきます。ま,自分のシステムのバグなら,自分で原因追求するだけなので関係ない話ですが。保守部隊に原因の調査を依頼します。自分が解析を依頼された場合は障害解析手順を参考に,どうにかしてください。原因の調査で,不具合箇所の見当はつきます。次にOSやプロセスの再起動,縮退運転,待機系への切り替えなど,障害をとりあえず回避する対策を実施します。ハードウエア障害で代替機がない場合や,システムの基本機能がバグっていた場合は,使用禁止にするしかありません。調査を依頼した結果として,暫定対策以外にモジュールや,ハードウエアの入れ替えが必要であれば,改めて実施します。障害報告書の作成ひととおり終わったら,ユーザに障害報告書を持って謝りにいきます。本体策までに時間のかかる場合は,本体策の前にいくこともあります。障害報告書には障害の概要,対応経緯,不良原因,対策などを書きます。ChipsSeesaaブログ広告この広告は60日以上更新がないブログに表示がされております。以下のいずれかの方法で非表示にすることが可能です。「広告を表示しない」にチェックを入れて保存する。ブログ×この広告は180日以上新しい記事の投稿がないブログに表示されております。