はじめに
コジマです。
製造工程からアサインされて、保守に入ってから「なんでこれちゃんとやってないの？」って
思うことが結構あります。
ただ、自分が上流工程に携わる立場だったら
要件定義や設計のフェーズで漏らしてしまいそうでもあるなと思って
つらつらまとめてみることにしました。
運用保守目線で障害原因になってしんどい、または障害が発生したときにしんどい
って観点で５つ挙げてみました、
1:容量設計
これをちゃんとやらないとDBサーバのデータが増えてディスクフルになったり、ログがたまりすぎてディスクフルになったりしてしまいます。
障害が発生したときにアーキテクチャのレベルから見直さなきゃいけなくなるのはかなりしんどいです。
- 最大ユーザーは何人くらい？
- 同時に利用するユーザーは何人くらい？
- 1日あたりどのくらいDBの使用量が増える？
- データの保持期間はどのくらい？
ということを洗い出して計算して見積もった容量にバッファ積んでおかないと
やっぱりしんどいですよね。
かなり骨折れる作業ではありますが、後々のことを考えると
2:エラー設計、ログ設計
過去携わった案件で、エラー設計、ログ設計は適当なところ多い気がします。
そのため自分でも理想の設計方針というのが実務レベルのナレッジとして溜められないつらみがあります。
想定されるエラーは一通りキャッチしておきたいですよね。
障害が発生したときに
- どんなログを見れば
- どういうエラーがあるかわかって
- どういう対処をすればいいかわかる
という観点から逆算するといいのかなと思ったりはしますね。
3:排他制御
当たり前のことかもしれませんが、やはり見逃してしまう可能性の大きいものなのではないかと思います。
DBへのUPSERT処理が行われるところでは排他制御実装していないとデータの不整合が発生し、ものによっては大きな障害となります。
修正範囲も大きくなるし排他制御を見落とすことによる代償は大きいです。
過去何回かそれに苦しめられてます。
何が大変って、再現させるのが大変なんすよ。
再現させるのが大変ってことはお客様に説明するのが大変だし、直した後のテストも大変なんですよ。
4:アプリのフォルダ構成
フレームワークつかってればある程度見通しは立ちますが、規模が大きくなるとフレームワークが用意したものから
さらに細分化していく必要が出たりします。
そこがぐちゃぐちゃだとソース追うのが大変になるんですよね。
リファクタするにも再設計が必要になるし、工数もかかるし大変なのです。
さいごに
SIerの端くれとして仕事している身ですが、正直理想論としては大体の人は必要だってわかっているけど、
顧客側の予算がそこまで下りなくて泣く泣く削られている場合が多いように感じます。
結果上流・製造の負債を保守が背負うことになるんですよね。
そりゃ開発だけやってたくなりますわ。
もう誰のせいとか言えないっすねぇ。
この記事を面白いまたは役に立ったと思ってくれた方は是非私のTwitter(@kojimanotech)を
フォローしてくれたらうれしいです！
システムエンジニアのつらい部分のあるあるなんかをエンタメにしたチャンネルを作りました。
チャンネルはこちら
つらい部分も楽しくなればと思っているのでよかったらチャンネル登録や高評価してくれたらうれしいです。
以上、コジマでした。
