社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

非機能要件(運用保守:前編)

非機能要件の中の運用保守の説明(前編)です。

運用と保守は、会社によって境界が異なるので、ここでは境界を気にせず記載します。

1.運用保守項目と役割分担

対象のアプリケーションの運用保守には、どのようなものがあって、誰が担当するのかを明確にします。

運用は運用部門、保守は開発部門、といったような大きな分担があって、「運用」に含まれる作業が何で、「保守」に含まれる作業が何で、それら個々の作業ごとに自社で対応する部分とベンダーに委託する部分を明確にします。

2.障害検知

障害を検知するのは当たり前の話しですが、ベンダーによっては非機能要件で明記しないと実装しないベンダーもいるので注意が必要です。

ベンダーが構築したアプリケーションの障害検知は漏れることは少ないですが、ミドルウェアやOSの障害検知は、何も言わないと検知の仕組みを実装してくれないベンダーもめずらしくありません。

ロードバランサーを利用している場合には、ロードバランサーからWebサーバーが切り離しされた場合にも検知が必要です。

サーバー含めてベンダーがシステム丸ごと用意する場合には、揉めることは少ないですが、サーバーやミドルウェアを自社で用意する場合には、OSやミドルウェアの障害検知は、ベンダーは自分たちの責任範囲外と捉えることが多いです。

また障害を検知するタイミングも決める必要があります。通常はリアルタイムでの検知ですが、例えば夜間バッチで障害が発生しても影響が少ないような機能は朝9時に検知するようなケースもあるかもしれません。

障害を検知した場合の通知方法も決める必要があります。オペレーターが24時間監視しているようなシステムと、オペレーターの監視がないシステムとでは、通知方法が異なるかもしれません。

3.稼働状況監視

稼働状況の監視は、「死活監視」、「リソース監視」、「パフォーマンス監視」の3つに分類されます。

f:id:SystemEngineers:20200823142214p:plain

さらにこれらは、監視対象のレイヤーによって以下のように整理することができます。

f:id:SystemEngineers:20200823162837p:plain

これらの中でも、特にミドルウェアのリソース監視とパフォーマンス監視は数が多いため、どこまで監視対象にするか全体感を持って検討する必要があります。

たくさん監視をすれば良いというものではなく、システムの規模や重要度によってどこまで監視をすれば良いのかが変わってきます。

小規模で利用者が少ないシステムを過剰に監視しても、無駄に運用コストが発生するだけですし、監視が形骸化してしまい本来見つけたい事象を見逃すリスクもあります。

また監視には、「アラーム検知」と「傾向分析」の2種類の監視方法があります。

アラーム検知は、リアルタイムで閾値を超えた事象を捉えます。サーバーの死活監視やリソース使用率の閾値超えなどがアラーム検知の対象となります。障害検知と同様に通知方法(オペレーターが気づくようにパトランプ鳴動、保守担当者にメール送信、等)も決める必要があります。

傾向分析は、リソース使用率やパフォーマンスの記録を時系列で確認することで、リソース枯渇や性能劣化の予兆を捉えます。どこくらい先まで予測するかは、拡張性要件で決めたスケールアウト、スケールアップに要する期間に依存します。例えばスケールアップをする方針でスケールアップに必要な期間が3ヶ月だった場合、傾向分析で1ヶ月先までシミュレーションしても手遅れです。この場合には最低でも3ヶ月先をシミュレーションして、リソース増設が期間的に手遅れにならないようにする必要があります。

またアラーム検知も傾向分析も、性能要件で設定をした各種の上限値を意識する必要があります。例えば同時接続数の上限を100で設定していた場合、今の同時接続数の利用状況がいくつなのかを知ることは重要です。先々月の同時接続数の月平均が50で、先月が60、今月が70だった場合、3ヶ月後には同時接続数が100に達する可能性があります。

このケースの場合、例えば同時接続数が70を超えたら警告メールを出す仕組みが「アラーム検知」です。上述のように毎月の同時接続数を確認して、3ヶ月後に上限に達するかもしれないと予測することが傾向分析です。

アラーム検知と傾向分析は、必ずしも両方実施する必要は無く、リソースの増加傾向や枯渇した場合の影響、拡張に要する期間等で、どちらかだけを実施する判断をすると過剰にコストをかけず効果的な監視をすることができます。

【振り返り】

運用保守の説明(前編)は以上で終了となります。次回は運用保守(後編)の説明をしていきたいと思います。

①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ/アクセシビリティ
⑧システム環境