2006年02月28日

SEに要求される力

SEとして大成するには、どういう能力が必要か考えてみました。
まあ、筆者が数時間考えただけなので、他にもいろいろあると思いますが、ご容赦を。

■全般
・文章作成技術
・報告、連絡、相談の徹底
・相手の立場になって考えれるか
・ひとりでかかえこまないか
・2徹、3徹を乗り切る体力
・英語の読み書きができるか

■対顧客折衝
・客、同業他社に対して仕様を押し通す折衝能力
・価格折衝に勝つ折衝能力
・大嘘を平気でつけるか
・客の雰囲気に合わせて出す技を変えられるか

■部下、PGへの指導
・部下への指導ができるか
・面倒見がいいか
・部下の悩みを察知できるか

■システム設計能力
・顧客から要件をヒアリングできるか
・与えられた具体的な要件から抽象的な仕様に変換できるか

■システム開発能力
・プログラミング能力
・プログラミング言語の習得能力
・仕様策定能力

■テスト能力
・大量データを流した場合にどうなるかの予想がつくか
・きわどいパターンを思いつけるか

■障害対応
・障害発生時になぜ?と考えて原因を追究する力

■姿勢・精神力
・客にいじめられても耐えられる精神力
・新しいモノに興味があるか
・新しい技術を使うべきところと、枯れた技術を使うべきところの見極めができるか
・SE関連業務の勉強が苦にならないか


ほかに、こういった能力が必要というのがあれば、教えてください。

人気blogランキング



posted by まる at 00:37| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年02月20日

富豪的プログラミングの弊害

最近の富豪的プログラミングに影響されてると、アルゴリズムを考えるのがおっくうになります。
ついつい、簡単に実装できるアルゴリズムを採用してしまいます。
しかし、実装する前に少しだけ考えてください。そのアルゴリズムで本当に問題ないのか。

大半の処理は性能に影響を与えません。しかし、一部の処理は確実に性能に影響を与えます。
その一部の処理だけは、手を抜かずに考えましょう。

実際に筆者がやらかした例を挙げてみます。

メタデータを管理するクラスを作り、メタデータ自身をファイルで保管していました。 データ量が膨大になるのは自明でしたので、データ自体の保存、読み込み処理は、当然、性能を意識して作成。 テストは何事もなく過ぎ、リリースしてしばらくのこと。

遅くて使えないと、顧客からクレームがきました。 顧客環境を調査したところ、メタデータの検索で時間がかかっている模様。 メタデータはたかだか100件程度だろうとタカをくくって、メタデータの探索は逐次探索としていました。 が、実際の運用環境では10000件を超えており、一件のメタデータの探索に、平均10ミリ秒消費していました。 ということは、全件の処理は10ミリ秒×10000件=100秒となります。 一回の処理に100秒かかるようでは、遅いといわれてもしょうがありません。 メタデータだから、そんなに件数がないとサボった罰です。逐次探索からハッシュ探索に切り替えたところ、1秒かからずに処理が完了し、問題は解決しました。

おかげで、顧客からイヤミを言われ、肩身の狭い思いをしましたとさ。

気に入った方はこちらもクリック。人気blogランキング

posted by まる at 23:42| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2006年02月13日

障害報告書のフォーマット

障害が起きたとき、なにが気分を重くするかっていうと、障害を顧客に伝える瞬間です。
ハードウエア不良なら自分の責任は少ないのでまだマシですが、プログラムのバグで、しかも本番機でトラブルとなると、営業や上司に押し付けて逃亡したくなります。

そうはいっても、技術的な話はSEに降ってくる宿命です。
そこで、障害報告書だけ書いて、客への押しつけちゃいましょう。 障害報告書は次の内容を書きます。

  • 概要
  • 現象
  • 原因
  • 対策
  • 経緯
■概要
障害の内容と対策を簡単に記します。顧客側の担当者は障害の詳細を知りたがりますが、上司や役員は概要だけで十分です。 そこで、概要を説明し、詳しく知りたい人には後の部分を読んでもらうようにします。
例:
2006年2月13日 22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。サーバの再起動、およびデータベースに対する同時接続数の増加を行い、当面の現象は回避。不具合を対策したモジュールの入れ替えを2月20日に行います。

■現象
障害の具体的な内容を記します。
いつ、どこで、なにが、どのようになったかを客観的に説明します。
例:
2006年2月13日 21:50より、XXXサイトへのアクセスが通常の100倍に増加。22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。 XXXサイトを構成するサーバX、サーバYを調査したところ、サーバXのデータベースにアクセスするプロセスがダウンしていました。

■原因
障害の発生要因を記します。
障害の原因と現象の関連が分かるように書きます。
例:
21:50より、XXXサイトへのアクセスが通常の100倍に増加。同時接続の増加により、データベースでの同時接続アクセス数を超過。 データベースからエラーが返った時点で、エラーを想定しない処理となっていたため、サーバのプロセスがダウン(不良点)。 サーバのプロセスがダウンしたため、XXXサイト全体の処理が停止し、無応答となりました。

■対策
障害の対策を記します。
対策には暫定対策と、本対策の2種類があります。暫定対策は、とりあえず現象を回避するための対策です。回避策とも呼びます。 本体策は、障害の原因を取り除く対策です。
例:
サーバXを再起動し、関連プロセスを再起動することで、プロセスを復旧。同時にデータベースへの同時接続数を増やすことで障害の原因を暫定的に回避しました。
このままでは、アクセスが増大した場合に、全ユーザのレスポンスが悪化します。原因を対策したモジュールを2月20日に入れ替えることで本対策とします。

■経緯
障害の対応経緯を記します。
例:
2006/2/1321:50頃ユーザからのアクセスが通常時の100倍に増大。
22:00データベース接続プロセスがダウン。
22:10監視アプリケーションによりプロセスダウンを検知。御社オペレータに通知。
22:15御社オペレータより弊社に連絡。調査開始。
22:30ログ採取後、サーバXの再起動を実施。サービスを再開。
23:00データベースのログより同時接続数を超過した場合のエラー処理に問題があると判明。同時接続数の上限を変更。
2006/2/14プログラムでの障害発生箇所を確認。同様の不良がないか見直しを実施。
2006/2/20対策完了版への差し替え予定。
posted by まる at 23:34| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2006年02月07日

障害対応手順

前回の予告どおり,障害対応の手順を説明します。

  1. 障害の発覚
    第一報は,顧客か,監視ツールのエラーとしてあがってきます。
    そこで,何が発生しているのか,どのシステムに影響があるのか,現象を明確にし,他人に伝えれるようにまとめます。

  2. ユーザへの通知
    ユーザに障害の発生を通知します。 障害があってもシステムには影響がなかったり,ダウン時間が短くユーザにバレないと考えたり,ユーザにバレても誤魔化せると踏んだ場合は,ユーザに通知しないこともありますが。

  3. 障害情報の取得
    システムの挙動がおかしいときに,再起動するとそれなりの確率で直ります。しかし,勝手に再起動すると,障害が再現しないことがあり,原因不明で片付けられてしまいます。
    二度と発生しない障害ならいいのですが,この手の障害に限って保守部隊のいないスキを狙ったかのように発生します。
    そこで,保守部隊に確認して,再起動しても問題ないか,再起動する前に取得しておく情報がないか,先に確認しておきます。
    ま,自分のシステムのバグなら,自分で原因追求するだけなので関係ない話ですが。

  4. 原因の調査
    保守部隊に原因の調査を依頼します。自分が解析を依頼された場合は障害解析手順を参考に,どうにかしてください。

  5. 暫定対策の実施
    原因の調査で,不具合箇所の見当はつきます。
    次にOSやプロセスの再起動,縮退運転,待機系への切り替えなど,障害をとりあえず回避する対策を実施します。 ハードウエア障害で代替機がない場合や,システムの基本機能がバグっていた場合は,使用禁止にするしかありません。

  6. 本体策の実施
    調査を依頼した結果として,暫定対策以外にモジュールや,ハードウエアの入れ替えが必要であれば,改めて実施します。

  7. 障害報告書の作成
    ひととおり終わったら,ユーザに障害報告書を持って謝りにいきます。本体策までに時間のかかる場合は,本体策の前にいくこともあります。障害報告書には障害の概要,対応経緯,不良原因,対策などを書きます。
posted by まる at 00:28| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。