アカウント名:
パスワード:
悪意の有無は兎も角として、日本の場合（アメリカでもそうなのかは知りませんが）、運用ノウハウやバグの回避方法なんかが特定メンバーの頭の中だけにあって、レイオフしてみたらシステムが動かなくなった、ということは発生しそうな気がするなぁ。
ちゃんとドキュメント作ればいいんだけど、システムの設計書は基本設計書とＤＢ設計書ぐらいしかない、運用手順書もない状態で、その上、工数的にドキュメント整備なんかしてる時間はないからそんな状態が延々と続いている、ってところは意外とあるんじゃないだろうか。
そんな感じで回されてるシステムだと、これから炎上するところが結構出てきてもおかしくないんじゃないかな、特にレイオフしたり値下げ目当てで安いエンジニアにすげ替えたりすると。
＃そんなシステムの運用保守やってるのでＡＣ＃止まったら社会的に見ても結構ヤバいところなんだがなぁ・・・＃つーか、発注先の企業が「詳細設計？そんなの金かかるからやらなくてもいいよ。」って、それでいいんかよ、とは思うが。
とても古いドキュメント:「データ不整合のアラートが出たら cleandb.sh を実行するんだ！」
cleandb.sh: 歴史的な経緯により、いつの間にかDBを全消去するスクリプトになってた
こんな状況でロクな引継ぎされなかったら大変な事になるけど、誰の所為になるんだろうね？おっと、わざとドキュメントを更新しなかったり、同じ名前のスクリプトを作ったわけじゃないよ？
# フィクションだけどAC
#1503355 [srad.jp]のACです。
うちにも似たようなのあるよ。十数年前（現行システムの２世代前）に作られた「夜間バッチでDB更新がうまくできたかチェックする手順書」なるものがあって、実行すると、かなりの（おそらく５０％以上）高確率でデッドロックが発生して本番系のアプリを殺します。そんなもん流したら修羅場どころの騒ぎじゃないので実際にどうやっているかというと、全然別の手順でDB更新内容を確認しているわけだけど。
で、実際のところ上記の「手順書」だと１０分で終わる内容だから運用工数は取ってないけど、実際には「別の手順」だと２時間ぐらいかかるから、担当者（交代で回ってくる）は２時間早く出勤してチェックするのが常態化。ちなみにサービス残業ならぬサービス早朝出社。
他にも「週１で流さないとシステムが止まるけど、特定の人のＰＣにしか入ってないＳＱＬ」なんてのもあるからかなり危険だなぁ、そういえば。アレの担当者が事故か病気でもしたら……。（うちが出したバグに起因する仕様なので、そういうＳＱＬを共有フォルダに置いて顧客に見られると責任追及されるから置けないとかそんな理由。）
＃そしてさっき仕事仲間から「お前、スラッシュドットってサイト見てる？」と電話があったからこれ以上は自重。＃建前上は見てないってことにしといてくれや（謎）＞同志
>＃そしてさっき仕事仲間から「お前、スラッシュドットってサイト見てる？」と電話があったからこれ以上は自重。リアルで「おっと、だれか来たようだ」かよｗ
＞うちにも似たようなのあるよ。十数年前（現行システムの２世代前）に作られた＞「夜間バッチでDB更新がうまくできたかチェックする手順書」なるものがあって、＞実行すると、かなりの（おそらく５０％以上）高確率でデッドロックが発生して本番系のアプリを殺します。
そもそも、何故チェックするだけの仕組みでロックが発生しているのか。
更新時間の記録などでデータのバージョンを確認する仕組みがなくて、チェックにもロックが必要だったりするのかな？
# え？激しい更新があるDBだとそれじゃ駄目？# 大丈夫。バッチで動いてる仕組みなんだから、その時間帯はそんな流量無いって。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
悪意の有無は兎も角として (スコア:4, 興味深い)
悪意の有無は兎も角として、日本の場合（アメリカでもそうなのかは知りませんが）、運用ノウハウやバグの回避方法なんかが特定メンバーの頭の中だけにあって、レイオフしてみたらシステムが動かなくなった、ということは発生しそうな気がするなぁ。
ちゃんとドキュメント作ればいいんだけど、システムの設計書は基本設計書とＤＢ設計書ぐらいしかない、運用手順書もない状態で、その上、工数的にドキュメント整備なんかしてる時間はないからそんな状態が延々と続いている、ってところは意外とあるんじゃないだろうか。
そんな感じで回されてるシステムだと、これから炎上するところが結構出てきてもおかしくないんじゃないかな、特にレイオフしたり値下げ目当てで安いエンジニアにすげ替えたりすると。
＃そんなシステムの運用保守やってるのでＡＣ
＃止まったら社会的に見ても結構ヤバいところなんだがなぁ・・・
＃つーか、発注先の企業が「詳細設計？そんなの金かかるからやらなくてもいいよ。」って、それでいいんかよ、とは思うが。
Re:悪意の有無は兎も角として (スコア:2, おもしろおかしい)
とても古いドキュメント:
「データ不整合のアラートが出たら cleandb.sh を実行するんだ！」
cleandb.sh:
歴史的な経緯により、いつの間にかDBを全消去するスクリプトになってた
こんな状況でロクな引継ぎされなかったら大変な事になるけど、誰の所為になるんだろうね？
おっと、わざとドキュメントを更新しなかったり、同じ名前のスクリプトを作ったわけじゃないよ？
# フィクションだけどAC
Re:悪意の有無は兎も角として (スコア:4, おもしろおかしい)
#1503355 [srad.jp]のACです。
うちにも似たようなのあるよ。十数年前（現行システムの２世代前）に作られた「夜間バッチでDB更新がうまくできたかチェックする手順書」なるものがあって、実行すると、かなりの（おそらく５０％以上）高確率でデッドロックが発生して本番系のアプリを殺します。
そんなもん流したら修羅場どころの騒ぎじゃないので実際にどうやっているかというと、全然別の手順でDB更新内容を確認しているわけだけど。
で、実際のところ上記の「手順書」だと１０分で終わる内容だから運用工数は取ってないけど、実際には「別の手順」だと２時間ぐらいかかるから、担当者（交代で回ってくる）は２時間早く出勤してチェックするのが常態化。ちなみにサービス残業ならぬサービス早朝出社。
他にも「週１で流さないとシステムが止まるけど、特定の人のＰＣにしか入ってないＳＱＬ」なんてのもあるからかなり危険だなぁ、そういえば。アレの担当者が事故か病気でもしたら……。（うちが出したバグに起因する仕様なので、そういうＳＱＬを共有フォルダに置いて顧客に見られると責任追及されるから置けないとかそんな理由。）
＃そしてさっき仕事仲間から「お前、スラッシュドットってサイト見てる？」と電話があったからこれ以上は自重。
＃建前上は見てないってことにしといてくれや（謎）＞同志
Re:悪意の有無は兎も角として (スコア:2, おもしろおかしい)
>＃そしてさっき仕事仲間から「お前、スラッシュドットってサイト見てる？」と電話があったからこれ以上は自重。
リアルで「おっと、だれか来たようだ」かよｗ
Re: (スコア:0)
＞うちにも似たようなのあるよ。十数年前（現行システムの２世代前）に作られた
＞「夜間バッチでDB更新がうまくできたかチェックする手順書」なるものがあって、
＞実行すると、かなりの（おそらく５０％以上）高確率でデッドロックが発生して本番系のアプリを殺します。
そもそも、何故チェックするだけの仕組みでロックが発生しているのか。
更新時間の記録などでデータのバージョンを確認する仕組み
がなくて、チェックにもロックが必要だったりするのかな？
# え？激しい更新があるDBだとそれじゃ駄目？
# 大丈夫。バッチで動いてる仕組みなんだから、その時間帯はそんな流量無いって。