忍者ブログ

ひつ(じのひよこが)プログラミングします。
お仕事や趣味で困ったこととか、何度も「あれ?どうだったかしら」と調べたりしたこととか、作ったものとか、こどものこととかを書きます
★前は週末定期更新でしたが今は不定期更新です

2024/12    11« 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  »01

恒久対応策ではないもの

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

コメント

ただいまコメントを受けつけておりません。

恒久対応策ではないもの

最近、障害発生時にあがってくる恒久対応策に対してフィードバックコメントを返す機会が多い。以下の場合はだいたい突っ返している。

ミスした人に「注意喚起」するのを恒久対応策とする
ミスをするということはミスをする構造になっている、ということである。多少注意を促したところで「多忙だったから」「焦っていたから」で同じ事故が発生するのは目に見えている。ミスするような部分を機械化するなどして対応を行うのが正解。次善の策としてプロセスでカバーするという策もあるが、工数が単純に増えるためあまり良くない。ただただそのメンバーの注意欠陥で障害が発生するのであれば、そのメンバーには別のタスクを割り当てるべきだ。ただし、有効な恒久対応策が実現するまでの時間稼ぎとしての実施であれば許容する。
意味のないダブルチェックやトリプルチェックである
ダブルチェックに意味がない、とは言い難いし、意味がある場面もある。しかし、単純作業としてのダブルチェックには意味がない。ダブルチェックが提案された場合にそのダブルチェックに意味がありそうか否かを確認すること。同じことを違う人が確認するだけならばそのダブルチェックには意味がない。別の人に「検算させる」ものであると上手く行くかもしれない。ただし、有効な恒久対応策が実現するまでの時間稼ぎとしての実施であれば許容する。
原因不明なので恒久対応策しない
ログが足りないとかそういったことで原因が追えないことは現実的に発生し得る。そうであればどんなログを足せばいいのか、どんな初期対応を次は行うべきなのかを記載して「これで次は恒久対応策を練られるようにする」等といった対応を行う。ただで転んではならない。
実行にデカいデメリットがある
実行した結果デグレが発生したり、特定の超人に依存した策だったりする場合は無論不可とする。ただし、多少のデメリットについては甘受するべき場面もあるので相談が必要である。恒久対応策の提案者ではなく、より上の立場の人がジャッジするべきことかもしれないので場合によっては偉い人にエスカレーションすること。

だが、運用に直に入っていない人間が恒久対応策の話を聞いても的外れなフィードバックを返してしまうこともある。運用に入って実情を知れていればいいのだが、そうでない場合は当人と会話してコンテキストの差を埋める方がよい。

PR

コメント

ただいまコメントを受けつけておりません。

ブログ内検索

P R