SIerで必要な技術力レベルについて【Lv4：トラブルシュート】

どうも、陽翔(@engineer_yosho)です。

未経験でエンジニアを目指すあなたへ。 どれくらいの技術力的があれば現場で通じるか、気になっていませんか？

答えを言います。

SIの現場のエンジニアになるのであれば、高い技術力は必要ないです。ただし、並レベルのコミュニケーション能力は必要です。

つまり、並レベルの技術力と並レベルのコミュニケーション力があれば通用します。

陽翔

本記事のシリーズでは必要な技術力レベルを４つのレベルで解説いたします。

SIerで必要な技術力レベルについて【エンジニアを目指す人向け】シリーズTOPへ

本記事では【Lv4】トラブルシュートについて説明します。

是非、最後までお付き合いください。

さあ、どうぞ。

SIエンジニアは具体的にどのくらいの技術力が必要か？

前提までのおさらいです。

• SIプロジェクト
• 業務アプリケーション開発
• Webアプリケーション
• サーバーサイドはJava＋RDB

そして前々回、前回で【Lv1】～【Lv3】までを話しました。

• 【Lv1】最低限必要なレベル
• 【Lv2】次の段階はスピードアップと品質向上
• 【Lv3】パフォーマンスチューニング

ここまでくれば出来るエンジニアの仲間入りです。

【Lv3】のパフォーマンスチューニングよりも更に高いスキルが必要なのがトラブルシュートです。

【Lv4】トラブルシュート

トラブルシュートとは障害対応の事です。トラブルシュートができるようになると頼られるエンジニアの仲間入りです。

システム構築プロジェクトがいよいよ本番リリースを迎える日を想像してください。

大きなプロジェクトほど必ず何かしら本番障害が発生します。この初期障害を対応して定着化するまでが、構築プロジェクトとしての使命です。

本番系システムで障害が発生した際の対応は超重要です。トラブルシュートが出来るようになると【Lv4】です。SI系の業務アプリ開発エンジニアとしては、技術力的にここが到達点だと、私は考えています。

トラブルシュートとは、こういうものです。

クライアントとの調整まで含めたトラブルシュートの全体像はこんな感じです。

本記事のテーマはSIエンジニア必要な技術レベルについてなので、「3.原因調査」と「6.必要に応じて暫定対応」についてのみ触れます。実際のエンジニアの作業についてのイメージを持ってもらえるようにちょっと具体的に話します。

「7.本格対応」はどうしたんだ？と思われるかもしれませんが、原因判明してリリース日の調整が出来ていれば、それは【Lv4】ではないので割愛です。

原因調査

ユーザーからの障害連絡を元に原因調査を行います。この時点で得られる情報は、画面のここの表示がおかしいとか、この操作ができないのでおかしい、とかそういうレベルです。

そのなけなしの情報を元に調査を進めていきます。

クライアントへの業務影響が大きい場合は、本日中に何とかするのがMUSTだとか、1時間おきとかに電話かかってきてどうなってるのか、言われます。

そこそこ追い込まれた状況になりますが、１つづず冷静に調査を進めていく必要があります。このあたりは慣れも必要です。

データ調査については、ここで真のSQL力が試されます。その場で、SQLをどんどん書きながら、問題になっている箇所やその関連箇所のデータを見ていかなければなりません。

本番データが見れる環境は、隔離された特別な本番ルームと呼ばれるところで、ネットの接続環境はなかったり、携帯やPCの持込がNGだったりとかなりの制限があります。

何も見ずにSELECT文をスラスラ書けるレベルがMUSTになります。私は良くSQLは日本語レベルで使えるようになろう、とちょっと大げさに言っています。でも、イケてるエンジニアはこのような事を経験してきているので、SQLのレベルは間違いなく高いです。

というか、エンジニアの本当の腕が知りたければ、トラブル対応させてるとすぐにわかります。普段、割と口が達者でそれっぽいエンジニアでも、トラブルシュートになったら、からっきし存在感なくなる人がいるんですが、まだまだ修行が足りないと思います。

業務レベルの個別の不具合ならまだいいのですが、パフォーマンスのスローダウンとかシステムダウンなどの大規模障害、全面障害の場合は、インフラ系の担当とも協力しながら、更に細かい調査を進めていきます。コミュニケーション力も必要で、この辺がまさにエンジニアとしての総合力の見せ場になります。

必要に応じて暫定対応

不具合の原因調査が終われば、後はプログラムを修正してリリースという事になります。しかし、業務影響の度合いによっては、即時に対応が必要なケースがあります。

プログラムを修正して、またテストをしてリリースまでの必要な手続きを踏んでという事をやると、数日必要とななったり、リリース自体が週末しかできないというような制約もあったりします。

そうなってくると、プログラムのリリースまでの間、業務影響を軽減する為に本番データを修正して一時的にしのぐという事をします。複雑に絡み合ったデータをつじつまが合うように修正するというのは、結構たいへんな事です。

データベースの設計およびプログラムの挙動を把握していないと、正しい状態にする事ができません。また、データ修正後の確認テストのケースをわりと短時間で設定しなくてはいけなくて、やっぱり全体の把握が必要になります。

また、このデータ修正はリスクも大きいです。万が一、データ修正の方針を読み間違えると、2次障害を引き起こし場合によっては、更に大きな問題に発展したりしますので、本当にミスは許されない状況になります。

さて、トラブルシュートについて、イメージが伝わったでしょうか？

トラブルシュートは技術力だけでなく本当に総合力が必要です。頼られるエンジニアとはこれが出来るレベルだと考えています。

最後までお付き合い頂きありがとうございました。

SIerで必要な技術力レベルについて【エンジニアを目指す人向け】シリーズTOPへ