小学生のとき、ビルマの竪琴の読書感想文を書きました。
あまり真面目な子どもではなかったので、どこかからか上手い読書感想文を見つけてきて、そこに多少の自分なりのアレンジを加えて提出しました。
何かを参考にしたことはバレるだろうけれど、でも丸写しではないので、怒られることはないだろうと思っていたら、予想外に担任の先生が大絶賛。危なくどこかのコンクールに推薦されるところでした。
親にも褒められ、真面目ではないけれど小心者の私は、推薦が他の生徒に決まるまでは、罪悪感に苛まれる毎日。
人の真似をして褒められても、全然うれしくないのだと、身に染みることができました。
私は些細なことでも、自分の考え、自分のやり方、自分の作ったものにこだわるのですが、この時のトラウマが最初のきっかけだった気がします。
非機能要件の中の運用保守の説明（前編）です。
運用と保守は、会社によって境界が異なるので、ここでは境界を気にせず記載します。
１．運用保守項目と役割分担
対象のアプリケーションの運用保守には、どのようなものがあって、誰が担当するのかを明確にします。
運用は運用部門、保守は開発部門、といったような大きな分担があって、「運用」に含まれる作業が何で、「保守」に含まれる作業が何で、それら個々の作業ごとに自社で対応する部分とベンダーに委託する部分を明確にします。
２．障害検知
障害を検知するのは当たり前の話しですが、ベンダーによっては非機能要件で明記しないと実装しないベンダーもいるので注意が必要です。
ベンダーが構築したアプリケーションの障害検知は漏れることは少ないですが、ミドルウェアやOSの障害検知は、何も言わないと検知の仕組みを実装してくれないベンダーもめずらしくありません。
ロードバランサーを利用している場合には、ロードバランサーからWebサーバーが切り離しされた場合にも検知が必要です。
サーバー含めてベンダーがシステム丸ごと用意する場合には、揉めることは少ないですが、サーバーやミドルウェアを自社で用意する場合には、OSやミドルウェアの障害検知は、ベンダーは自分たちの責任範囲外と捉えることが多いです。
また障害を検知するタイミングも決める必要があります。通常はリアルタイムでの検知ですが、例えば夜間バッチで障害が発生しても影響が少ないような機能は朝9時に検知するようなケースもあるかもしれません。
障害を検知した場合の通知方法も決める必要があります。オペレーターが24時間監視しているようなシステムと、オペレーターの監視がないシステムとでは、通知方法が異なるかもしれません。
３．稼働状況監視
稼働状況の監視は、「死活監視」、「リソース監視」、「パフォーマンス監視」の３つに分類されます。
さらにこれらは、監視対象のレイヤーによって以下のように整理することができます。
これらの中でも、特にミドルウェアのリソース監視とパフォーマンス監視は数が多いため、どこまで監視対象にするか全体感を持って検討する必要があります。
たくさん監視をすれば良いというものではなく、システムの規模や重要度によってどこまで監視をすれば良いのかが変わってきます。
小規模で利用者が少ないシステムを過剰に監視しても、無駄に運用コストが発生するだけですし、監視が形骸化してしまい本来見つけたい事象を見逃すリスクもあります。
また監視には、「アラーム検知」と「傾向分析」の２種類の監視方法があります。
アラーム検知は、リアルタイムで閾値を超えた事象を捉えます。サーバーの死活監視やリソース使用率の閾値超えなどがアラーム検知の対象となります。障害検知と同様に通知方法（オペレーターが気づくようにパトランプ鳴動、保守担当者にメール送信、等）も決める必要があります。
傾向分析は、リソース使用率やパフォーマンスの記録を時系列で確認することで、リソース枯渇や性能劣化の予兆を捉えます。どこくらい先まで予測するかは、拡張性要件で決めたスケールアウト、スケールアップに要する期間に依存します。例えばスケールアップをする方針でスケールアップに必要な期間が３ヶ月だった場合、傾向分析で１ヶ月先までシミュレーションしても手遅れです。この場合には最低でも３ヶ月先をシミュレーションして、リソース増設が期間的に手遅れにならないようにする必要があります。
またアラーム検知も傾向分析も、性能要件で設定をした各種の上限値を意識する必要があります。例えば同時接続数の上限を100で設定していた場合、今の同時接続数の利用状況がいくつなのかを知ることは重要です。先々月の同時接続数の月平均が50で、先月が60、今月が70だった場合、３ヶ月後には同時接続数が100に達する可能性があります。
このケースの場合、例えば同時接続数が70を超えたら警告メールを出す仕組みが「アラーム検知」です。上述のように毎月の同時接続数を確認して、３ヶ月後に上限に達するかもしれないと予測することが傾向分析です。
アラーム検知と傾向分析は、必ずしも両方実施する必要は無く、リソースの増加傾向や枯渇した場合の影響、拡張に要する期間等で、どちらかだけを実施する判断をすると過剰にコストをかけず効果的な監視をすることができます。
【振り返り】
運用保守の説明（前編）は以上で終了となります。次回は運用保守（後編）の説明をしていきたいと思います。
①可用性
②性能
③拡張性
④運用保守
⑤移行
⑥セキュリティ
⑦ユーザービリティ／アクセシビリティ
⑧システム環境
夏生まれで夏が大好きなので、暑いのも全然気になりません。
自宅でテレワーク中も冷房いらず。たまに扇風機をつけるくらい。
数年前までは冷房を一切使わなかったのですが、ここ数年の暑さは半端ないので、夏のピークの１、２週間は夜寝る時だけ冷房を入れるようになりました。
テレワークになって、たまに天気の良い日はベランダで仕事をしているのですが、先日もベランダで仕事をしたところ、直射日光は避けていたのにPCが高熱を発生。
私のPCなのに、夏に弱いみたいです。
テレビでも連日「暑すぎる」と騒いでいますが、暑いと思うから暑く感じるのであって、太陽の恵みをたくさん頂いていると思えば、快適に過ごせるのではと思います。
通勤定期代が停止されるようです。
月に１回くらいしかオフィスに行っていないので妥当な判断ですが、定期代丸儲けと喜んでいたので、痛恨の極みです。
定期代支給の代わりに、在宅勤務手当が出るそうですが、月額3,000円程度を予定しているようです。私の場合、定期代が月換算で15,000円くらいかかっているので、損したわけではないのですが、損した気分・・・。
一般的には在宅勤務手当って、いくらくらい支給されているのか、早速ネットで検索。
一時金のところもあったりして比較しにくい。
そもそも比較しても自分の手当が増えるわけでないので意味ないのですが、せめて5,000円くらいは欲しいなあと。
がっかりです。
高所恐怖症です。
子どもの頃から高いところが苦手でした。高いビルの上とかジェットコースターとか、絶対に安全な高所は大丈夫なのですが、野生？の高いところは全く駄目です。
自然は好きなのですが、山登りは急斜面が怖いので登る山は厳選します。吊り橋は頑丈なものでも、基本NG。最近流行っているフォレストアドベンチャーにも一度行きましたが、楽しさゼロでした。
周りに理解してもらえないのが、足下が見えないと、それが３０センチの高さでも怖いということ。
トレッキングツアーに参加したとき、身長より高い岩にへばりついて動けなくなったことがあります。
手を離したら人生終わると思って、脂汗をかきながらガイドさんの声も無視して、自分時間で１時間ほど岩にへばりついていました。
その時の地面までの高さが３０センチほど・・・。
どうやって降りれたのか記憶がありませんが、無事に着地できて一息ついたときの、ガイドさんやツアー同行者たちの苦笑まじりの微妙な反応・・・。
怖さというものは、理屈では理解できないものなのです。
先日、人事からテレワークについてのアンケートがあり、集計結果が公表されました。
対象は本社勤務の500人。
通勤ストレスからの開放を感じている人は、80%。関西からの単身赴任が多く、近場に住んでいる人が多いことを考えると、妥当な結果です。
ところが・・・
理想の在宅勤務の頻度のアンケートでは、なんと50%が週1,2回を希望。
週3,4回を希望している人は25%、私を含む週5日を希望している人は、たったの2%・・・。
経営層だけでなく、従業員も考え方が保守的なのでしょうか。それともITとは違う職種の違いなのでしょうか。
コロナ前は運用されていなかったテレワーク。コロナが収束したら、またテレワークがなくなりそうです。
