アカウント名:
パスワード:
って印象ですね。もっとgdgdそうな所もありそうだけど。
手順書記載ミスによるコマンド誤りって、まともにテストできる環境がなかったとかスケジュールに無理があったとか、もっと根本の原因があるんでないかい？これで報告終わりだとすると、きっとまたらやかすな。
スケジュールの問題ではないでしょう。テスト環境に関しては、大規模になるほど用意するのが猛烈に困難になるから難しい問題ですな。
中小企業の社内システムだったら全然問題ないんだけどね・・・。
基本的に、今現状での役員、上層から見た現場は「手順書あれば誰でもできるんでしょ？」という認識止まりなのが、この手のトラブルが無くならない一因ではありますね。
本来、ここで必要とされる人間は通常作業はできて当たり前、トラブル時に瞬間的に状況把握して対処、もしくは現状報告して、無理なら無理といえる人なんですけど普段のコストカットでそういう人間をどんどん切って、安い使えない人間ばかりをこういうところに投入してきた結果なので、自業自得ですね
特にエンジニアが現場判断で障害回避しても、そんな指示してないと怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとかちょっと冷遇されすぎですよね
サーバの新規導入でconfigが間違ってて、とあるプロセスが動かなかった。ここで、現場の作業員が何を考えたか自分でconfig修正してプロセス動かして、動かしたあとに修正を元に戻して、作業完了の報告を上げやがった。数カ月後の計画停電で発覚、その作業員は出禁、といったことを思い出した。
貴方の発想は危険すぎて論外です。学生さんですか？
まさに「手順書あれば誰でもできるんでしょ？」の状態が正しいんです。そこに持っていくために力を尽くすのがエンジニアであり、その露払いをするのがマネージャです。
自称社会人 vs 自称社会人ファイッ!!
その手順書至上主義の問題点は、「人間はミスをするものだ」という当たり前の視点の欠如と、現場での臨機応変な対応の否定にあると思います。
現場での作業ミスと手順書作成時のミスは、両方とも発生する恐れがあることに変わりはないはずなのに、手順書は優秀な人間が作るものであるから大丈夫とでも思われているのか、そこでのミス回避の方策は あまり練られていないのが実情ではないでしょうか。
そして、確かに現場で勝手なことをやられては収拾がつかなくなるので、「手順書に書かれてあること以外はやるな」と指示するのは間違ってないんです。間違ってな
手順書を作る開発側と、本番環境の作業を担当する運用側との、業務の違いや役割分担を理解してからコメントしてくれ。
ミス回避の方策として、まず切り戻し手順の整備、危険工程を手順書に書くようになっている。作業前に開発と運用で手順書の読み合わせをして、手順書に間違いや記載不足があれば、当然運用から指摘が入る。
元コメでは「臨機応変な対応」をえらく称賛しているが、それはやっちゃいけない禁じ手だよ。
「この手順書のこの箇所、間違ってるんじゃない？」と判断した現場の人が、往々にしてトラブルを引き起こすんですけどね。
今回の件ではどうだったか知りませんが、難易度の高い作業だと手順書を作成した担当者も同席することがあります。ただし本番環境は触れないので、運用担当者が実行したコマンドの結果チェックなどをやります。
そもそも想定外の障害（事象①）を起こした時点で作業中断、切り戻しするのが普通だよね。事前に検証をしてれば想定外の事象は起こらないかっていうとそんなことない。そんな時また作業中断の判断ができず先に進むようだと、またやらかすよ。
本当に必要なのは適切な切り戻し手順と、その判断基準。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
内情はgdgd (スコア:0)
って印象ですね。もっとgdgdそうな所もありそうだけど。
Re: (スコア:0)
手順書記載ミスによるコマンド誤りって、まともにテストできる環境がなかったとかスケジュールに無理があったとか、もっと根本の原因があるんでないかい？
これで報告終わりだとすると、きっとまたらやかすな。
Re: (スコア:0)
スケジュールの問題ではないでしょう。
テスト環境に関しては、大規模になるほど用意するのが猛烈に困難になるから
難しい問題ですな。
中小企業の社内システムだったら全然問題ないんだけどね・・・。
Re: (スコア:0)
基本的に、今現状での役員、上層から見た現場は「手順書あれば誰でもできるんでしょ？」
という認識止まりなのが、この手のトラブルが無くならない一因ではありますね。
本来、ここで必要とされる人間は通常作業はできて当たり前、トラブル時に
瞬間的に状況把握して対処、もしくは現状報告して、無理なら無理といえる人なんですけど
普段のコストカットでそういう人間をどんどん切って、安い使えない人間ばかりを
こういうところに投入してきた結果なので、自業自得ですね
特にエンジニアが現場判断で障害回避しても、そんな指示してないと
怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとか
ちょっと冷遇されすぎですよね
Re: (スコア:0)
特にエンジニアが現場判断で障害回避しても、そんな指示してないと
怒られたり、現場判断で損害少なくしても、上司がケツ持ちしてくれないとか
ちょっと冷遇されすぎですよね
サーバの新規導入でconfigが間違ってて、とあるプロセスが動かなかった。
ここで、現場の作業員が何を考えたか自分でconfig修正してプロセス動かして、
動かしたあとに修正を元に戻して、作業完了の報告を上げやがった。
数カ月後の計画停電で発覚、その作業員は出禁、といったことを思い出した。
Re: (スコア:0)
貴方の発想は危険すぎて論外です。学生さんですか？
まさに「手順書あれば誰でもできるんでしょ？」の状態が正しいんです。
そこに持っていくために力を尽くすのがエンジニアであり、その露払いをするのがマネージャです。
Re:内情はgdgd (スコア:1)
ええ、いってることは正しいんですよ、ただ現実にはまず実現不可能というだけで
で結果として元ACがいってたような事態に陥るわけよ
Re: (スコア:0)
自称社会人 vs 自称社会人
ファイッ!!
Re: (スコア:0)
その手順書至上主義の問題点は、「人間はミスをするものだ」という当たり前の視点の欠如と、現場での臨機応変な対応の否定にあると思います。
現場での作業ミスと手順書作成時のミスは、両方とも発生する恐れがあることに変わりはないはずなのに、手順書は優秀な人間が作るものであるから大丈夫とでも思われているのか、そこでのミス回避の方策は あまり練られていないのが実情ではないでしょうか。
そして、確かに現場で勝手なことをやられては収拾がつかなくなるので、「手順書に書かれてあること以外はやるな」と指示するのは間違ってないんです。間違ってな
Re:内情はgdgd (スコア:1)
手順書を作る開発側と、本番環境の作業を担当する運用側との、業務の違いや役割分担を理解してからコメントしてくれ。
ミス回避の方策として、まず切り戻し手順の整備、危険工程を手順書に書くようになっている。
作業前に開発と運用で手順書の読み合わせをして、手順書に間違いや記載不足があれば、当然運用から指摘が入る。
元コメでは「臨機応変な対応」をえらく称賛しているが、それはやっちゃいけない禁じ手だよ。
Re: (スコア:0)
「この手順書のこの箇所、間違ってるんじゃない？」と判断した現場の人が、往々にしてトラブルを引き起こすんですけどね。
Re: (スコア:0)
今回の件ではどうだったか知りませんが、難易度の高い作業だと手順書を作成した担当者も同席することがあります。
ただし本番環境は触れないので、運用担当者が実行したコマンドの結果チェックなどをやります。
Re: (スコア:0)
そもそも想定外の障害（事象①）を起こした時点で作業中断、切り戻しするのが普通だよね。
事前に検証をしてれば想定外の事象は起こらないかっていうとそんなことない。
そんな時また作業中断の判断ができず先に進むようだと、またやらかすよ。
本当に必要なのは適切な切り戻し手順と、その判断基準。
Re: (スコア:0)
しかし検証不足で切り替えがトラブった挙げ句、いざというときの切り戻しもトラブって大規模障害発生ってなんというお約束。