冷たい方程式（26） Daydream Believer
デモは予定どおりに進行していたが、参加者の反応は微妙だった。大きな不満はないけれど、手放しで絶賛するほどでもない、といったところだろうか。
そんな中途半端な評価の原因は、不定期に発生するレスポンス遅延によって、進行が妨げられることがあったからだ。それぞれ数秒から10数秒に過ぎなかったが、頻発するとどうしても目についてしまう。大抵の人はうまくいっている事象よりも、その逆の事象に強い印象を抱くものだ。事実、大部分の参加者の興味は、新システムで改善された機能や、効率化された業務フローなどよりも、不可解なレスポンス遅延の発生の方に向けられているようだった。あたしだって単にデモを見に来ただけだったら、同じことを楽しんだにちがいない。
「あ、また止まった」誰かがつぶやいた。「あ、動いた」
クスクス笑いが、そこかしこで起こった。スクリーン上では、渕上マネージャが、休暇区分マスタメンテナンス画面の説明をしているところだ。一覧から1つの休暇区分をクリックしたとき、10秒以上にわたって応答が返ってこない状態が発生していた。
「本番でも、こんなんじゃ、ちょっと困るなあ」人事部長が容赦ないコメントをつぶやき、同意のささやきが追随する。渕上マネージャは動揺している様子を見せないが、ときおり、あたしたちの方に非難するような鋭い視線を投げていた。その視線の先が、あたしなのか、ムツミさんなのか、サードアイの2人なのかは不明だ。
あたしはデモ終了後に発生する事態を想像して、暗澹たる気分になった。当然のことながら、渕上マネージャは、即座に原因を突き止めて対処するように命令するに決まっている。ところが、あたしは、原因の推測さえできていなかった。
デモを開始してきっかり45分後、渕上マネージャは10分間の休憩を宣言した。ほとんどの参加者が時間差で立ち上がり、伸びをしたり、携帯電話を取り出したりし始めた。
彼らが味わっているささいなぜいたくは、あたしには許されなかった。渕上マネージャが急ぎ足であたしの元に歩いてきて、小さいが鮮明な声で命じたのだ。
「この休憩の間に、遅延の原因を解消したまえ。直ちにだ」
10分では無理ですよ、とか、高度なマネジメントで何とかなりませんか、とか何とか言おうとしたあたしに、一切の反論を封じるガンマ線バーストのような強烈な視線を叩きつけると、渕上マネージャは踵を返して壇上に戻っていった。
――どうしろって言うのよ
迷いながら、あたしは後ろに顔を向けて、東海林さんの注意を引いた。東海林さんは難しい顔で黒野さんと何かを話していたが、あたしの視線に気付くと、何か？とでも言うように首を傾げた。
「なんか原因について思いついたことあります？」この際、個人的な好き嫌いの感情は脇によけておいて、あたしは東海林さんに小声で聞いた。「何でもいいので」
「そうですね」東海林さんは手元の資料に目を落とした。「はっきりとは分かりませんが、ある程度周期的に発生しているような気がしますね。TomcatのJVMのメモリ、最大値はいくつにしてあります？」
「取りあえず512ですけど……ちょっと調べてみます」あたしは向き直った。
――ヒープかな？
ひょっとすると、どこかでメモリリークでも起こしていて、ヒープが足りなくなって、頻繁にGCが発生しているのかもしれない。あたしは手元のノートPCで、jconsole を起動して、APサーバで動いているTomcatに接続してみた。
問題はないようだ。ヒープにはまだ余裕がある。他の項目にも切り替えてみたが、PermGen spaceなどにも異常はない。あたしは、また後ろを振り向いた。
「メモリには余裕があります」あたしは囁いた。「他には何か思い当たることはないですか？」
「それ、ちょっと見せてもらえますか？」
東海林さんの要求に応じて、あたしはノートPCの画面の向きを東海林さんの方へ向けた。東海林さんは後ろから手を伸ばして、マウスを数回操作しながら、しばらくグラフの動きを注視していたが、やがてあたしと同じ結論に達した。
「ヒープなんかは大丈夫そうですよ」マウスをあたしに返しながら、東海林さんは興味をそそられたような声で言った。「メモリ関係じゃないと思いますね」
「なにかバグですか？」黒野さんが心配そうな顔で聞いてきた。責任問題に発展することを怖れているらしい。八木社長の顔にも不安がよぎっている。
「いえ」あたしは取りあえず否定の言葉を返した。「そういう問題じゃないと思いますけどね」
「それは良かった」
両社の営業担当は、揃って安堵の表情を浮かべたが、東海林さんの顔は晴れなかった。ムツミさんを見ると、真剣な顔で何かのメモを睨んでいた。
「HotDeployとCoolDeployの差とか？」あたしは思いつくままを口にした。
「いや」東海林さんは即座に否定した。「Hotの方が遅くなるなら分かりますけどね。逆はないでしょ。ネットワーク関係はどうですか？ この部屋だけ違うサブネットだとか、DNSサーバが違って名前解決に時間がかかってるとか」
「いえ、そういうことはないと思いますね。このフロアは全部同じですから」
「何かサーバで重いバッチでも流してませんか？」
「ないですね」
あたしたちは、いくつかの仮説を提示しては、否定するというプロセスを何度か繰り返したが、原因の裾に触れるにも至らず、デモの再開の時間になってしまった。
「取りあえずTomcatを再起動してみたらどうですか？」
東海林さんの提案に、あたしは慌ててTeraterm を立ち上げ、APサーバにログインした。psコマンドでTomcatのプロセスを探しながら、前に座っていた磯貝課長に囁いた。
「すみません。Tomcatを再起動するので、渕上さんにもう一度、ログインしてもらうように言ってください」
磯貝課長は無言でうなずくと、壇上へと向かった。あたしは、その姿を視界の端で確認しつつ、Tomcatのプロセスを殺し、続けてserviceコマンドでTomcatを起動した。tail でcatalina.out を開き、起動状態を確認する。
「それでは再開します」渕上マネージャが宣言したのは、Tomcatが起動した3秒後だった。「では、休暇区分マスタメンテナンスの続きから」
あたしたちシステム関係者は、期待を込めてスクリーンを注視した。この再起動で現象が解消されれば、この場はしのげるのだけど。
「さて」東海林さんがこの状況を楽しんでいるような声でつぶやいた。「どうですかね」
何か足りないと思ったら、祈るのを忘れていた。あたしは軽く手を組んで祈った。祈るのは得意だ。
しかし、あたしのいい加減な祈りが届かなかったのか、しばらくすると、またもやレスポンス遅延が発生した。
――ダメだったか
あたしが頭を抱えたとき、いつの間にか戻ってきていた磯貝課長が、そっとあたしの肩をつついた。
「渕上さんがメモを書いてよこしたよ」困った顔だった。「何とかしろってさ。今すぐ」
「……」
今すぐと言われても困るんだけど。あたしは、時間稼ぎの提案をしてみた。
「一度、データベースを再起動してみるのはどうでしょう？」
「ああ、それもメモにあった」磯貝課長は手の中の紙片をちらりと見た。「APもデータベースも再起動は不可だって」
読まれてたか。これ以上、デモを中断したくないのだろう。あたしは顔をしかめた。
「そうなると、デモが終わるまでは手が出せませんよ」
GCログスレッドダンプを解析するという手もあるが、あいにく、現在実行しているTomcatのJVMの起動オプションには、-Xloggc などは付けていない。さっき再起動するとき付けておくべきだったのかもしれないが、-Xloggcはパフォーマンスの低下を招くから、事態を悪化させる役にしか立たなかっただろう。
「こうなるとメモリとかじゃないですね」東海林さんが後ろから囁いた。「データベースしか考えられないですよ」
「確かに、データベースっぽいですね……」
データベース関係に原因があるのだとすると、困ったことに何が原因なのか、特定するのは難しそうだ。どれか特定のテーブルに対するアクセスのみが遅い、とか、特定の処理を実行する場合のみ遅い、というのなら、取りあえずインデックスを張ってしまうとか、レコードを大量に削除するとか、対処のしようもある。ところが、この遅延は、どのテーブルに対しても、どの処理に対しても、公平に発生しているようだったから始末が悪い。
あたしが頭の中のシングルCPUを熱暴走寸前までフル回転させていると、隣の席でムツミさんが、ぽつりとつぶやいた。
「一定の間隔がありますね」
「え？」あたしはムツミさんの顔を見た。
「間隔ですよ。この遅くなってるやつ」ムツミさんは、スクリーンを見ながら取っていたメモを注視していた。「selectです」
「間隔って？」
「select文が実行されている間隔です」ムツミさんは辛抱強く繰り返した。「どうも3回に1度の割合で遅いみたいです」
「3回に1度？」あたしはムツミさんの言葉をオウム返しに繰り返した。どうもピンとこない。
ムツミさんは、RHODIAのメモを1枚ちぎって、あたしに渡した。薄闇の中で目をこらすと、画面上の操作と、実行されるSQLが時系列にメモされているのが分かった。
画面初期化
→ SQL：select文でマスタ一覧get
→ SQL：select文で区分選択肢一覧get
新規入力
入力内容確認 ***
→ SQL：区分名称重複チェック(select文)
登録実行
→ SQL：区分名称重複チェック(select文)
→ SQL：マスタ追加(insert文)
完了画面
入力画面へ戻る
→ SQL：select文でマスタ一覧get
一覧から選択 ***
→ SQL：selectマスタ(1record)
入力内容確認
→ SQL：区分名称重複チェック(select文)
更新実行
→ SQL：区分名称重複チェック(select文)
→ SQL：マスタ更新(update文)
完了画面
入力画面へ戻る ***
→ SQL：select文でマスタ一覧get
――ああ、なるほど
あたしは思わずうなった。
ムツミさんが言いたいことは分かった。休暇区分マスタメンテナンス画面は、ムツミさんが実装した画面なので、どの操作によってどんなSQL文が発行されるかは、頭に入っていたのだろう。それを並べて、レスポンス遅延が発生している部分をマークすると、select文3つごとに発生しているらしい。
「確かにそうみたいね、ありがとう」あたしはメモを返した。「でも、3回というのに何か意味が……」
あたしの思考回路の中で、バラバラになっていたパズルのピースが、急激に意味のある形になりつつあった。ひょっとして……もしかして……ことによると……たぶん……
あたしは思わず立ち上がった。パイプ椅子がガタンと大きな音を響かせ、全員の非難の視線が突き刺さってくる。あたしはそれらを無視して、前に座っていた磯貝課長にささやいた。
「すいません。ちょっとサーバを確認してきます」
磯貝課長が驚いた顔で何か言いかけたが、あたしは聞いていなかった。できるだけ静かに、しかし急ぎ足で会議室を出るという行動に移っていたからだ。
廊下に出ると、あたしは慎みをかなぐり捨てて、ITマネジメント課を目指して全力疾走した。1分で自席に飛び込むと、パスワードを叩いてスクリーンセイバーモードを解除する。急いでTeratermを起動すると、マスターDBサーバにログインした。
psqlでデータベースを開き、pg_stat_replication で、レプリケーション状態を確認したとき、あたしは自分のカンが当たっていたことを知った。レプリケーションノードは、スレーブDBの１つだけのはずなのに、2つめのノードが追加されていた。
2つめのノードは、テストサーバのIPアドレスだった。
「いつのまに……」
あたしは、vi でpgpool.conf を開いて、ロードバランスの設定を確認した。3つめのレプリケーションホストとして、テストサーバが記述されている。もちろん書いた記憶はない。
わかってみれば、レスポンス遅延の原因は単純だった。この設定だと、select文は3台のサーバに順番に割り振られる。ムツミさんが気付いた通り、3回に1回はテストサーバに対してselect文が発行され、そのときに遅延が発生していたのだろう。
でも、いくら本番環境に比べて性能が劣るテストサーバだからといって、あまりにも遅すぎるような気がする。実装やテストでも使っているが、10秒以上、レスポンスが返ってこないなどということは、これまでなかった。
あたしはため息をつきながらマスターDBサーバからログアウトすると、今度はテストサーバにログインした。postgresql.conf を開き、まずは定石どおり shared_buffers の値を確認するべく、スクロールする。
「おいおい……」
1024Mに設定してあったはずなのに、32Mになっている。他の値も見てみると、work_mem などが、軒並み低い値に書き換わっているのが分かった。これでは、さすがに遅くなるだろう。
DBサーバへのアクセスは、APサーバを除けば、ITマネジメント課内の特定のPC数台に制限してある。これは、アクセス権は最低限、必要な分のみ、という社内のネットワーク規定によるものだ。自分の席まで走ってきたのもそのためだ。
アクセス許可を持っている社員の中で、渕上マネージャはこういう些末な事柄には手を出そうとしないし、磯貝課長でないのは言うまでもない。ホライゾンやサードアイのメンバーはアクセスできない。あたしが突発的な記憶障害を発症したという些少な可能性を除けば、可能なのはひとりしかいない。
「あのばか……」
あたしは唇をかんだ。DBサーバにアクセスできるPCの中には、亀井くんのPCも含まれている。異動して席が替わっても、PCはそのまま持っていったから、IPアドレスもアカウントも変わらない。それらをそのままにしておいた自分のうかつさにも腹が立ったが、誰がこんなことを想像するだろうか。
おそらく亀井くんは、あたしが24日の午前中にデモ用データを作成し、サブDBとの間にストリーミング･レプリケーションの設定を行った後、テストサーバで同じことをやったのだろう。昨日の夕方までは、テスト用データでテスト作業を行っていたから、昨夜に行ったに違いない。インフラグループに異動になった時点で、残業禁止の制限からは解放されているのだから。
pgpool によるロードバランスの設定は、本番で使うかどうかは検討中だったのだけど、テストをするために設定の記述だけはしてあった。亀井くんとしては、pgpool.conf に、テストサーバの記述を追加するだけでよかったわけだ。
取りあえず、これを何とかしなければならない。あたしは、rootユーザーになって、postgresqlのサービスをstopした。これで、3つめのノードが無効になったはずだ。
あたしは、会議室へ引き返した。まだデモは続いている。ドアを細めに開けて、小声で磯貝課長を呼ぶと、課長は驚いたような顔で外に出てきた。
「どうですか？」
「ここ何分かは、遅くなってないみたいだね」磯貝課長はそう言うと、探るようにあたしの顔を覗き込んだ。「何か原因があったのかな？」
「ええ、まあ。ちょっとデータベースの設定のあれこれが……レプリケーションとか……」あたしは言葉を濁したが、磯貝課長は細部には拘泥しなかった。
「じゃあ、もう大丈夫だね？」
「だと思いますけど……すみません。もうちょっと確認したいことがあるので……」
あたしは、ITマネジメント課に戻ると、インフラグループの方へ足を向けた。インフラグループには、何人かの社員が席にいたが、その中に亀井くんの姿はなかった。ホワイトボードを見ると、マシンルーム、となっている。
もう一度自席に戻り、あたしは少しの間、次の行動を考えた。このまま会議室に戻り、デモの進行を見守っていた方がいいような気がする。別の問題が発生したときに、ここにいれば対処も簡単だ。でも、別の遅延工作が用意されていないとも限らないし、それは物理的なものであるかもしれない。
――こんなことして、何がしたかったのよ
これで、渕上マネージャが動揺して、役員たちの前でしどろもどろになる光景でも夢見ていたんだろうか。だとしたら、亀井くんは渕上マネージャのことがよく分かっていない。そんなシーンは白昼夢でしかない。何かのマニュアルででも、頭を叩いて、覚醒状態に引き戻してやらなければ。
少し迷った末に、あたしはコートをつかんで、ITマネジメント課を出た。エントランスを出るときには、小走りになっていた。
（続く）
この物語はフィクションです。実在する団体名、個人とは一切関係ありません。また、特定の技術・製品の優位性などを主張するものではありません。
コメント
ほっほう
だよねえ。仕掛けがこれだけってことはないよね。
犯人として挙げられるところまで含めて(部下の管理能力うんぬんとか)考えてのことなんだろか
BEL
まさかのテロ説的中かｗ
それにしても
日比野さんが「メモリには余裕があります」って言ったのに
東海林さんは「それ、ちょっと見せてもらえますか？」から
「メモリ関係じゃないと思いますね」とはよほど信用してないのですねｗ
それにしてもこのバランシングってセッション単位とかじゃなくクエリ単位なんですね。
不治ソフト
なんか興醒め。
亀井くん(まだ犯人か確定してないけど)にはこういう女々しい手段取って欲しくなかった。
でも、これで査問の機会を得て上層部に渕上の暗部暴露とかか？
23年生
ま、こんなもんでしょう
さそうたける
亀井の大馬鹿野郎・・・
こんな事しても、渕上マネージャーには何のダメージも与えられないのに。。。
たかが社内システムの社内向けデモ。
デモに失敗しても、会社には何も損失を与えてないから渕上マネージャーが責任を
問われる事はなく、
単に「スタッフ規定違反」で亀井君が懲戒処分に処せられるだけ。
仮に、本番サーバーを物理的に破壊するとか本番データを壊すとかすれば、
会社に損失を与える事態なので上席の責任問題に発展するだろうけど、
渕上マネージャーは亀井君の上長ではなく別部署の人間なので、
組織の論理からすると責任を問われるのはITマネジメント課の磯貝課長とかであ
り、
亀井君に対して人事権を持ってない渕上マネージャーには責が及ばない可能性
が。。。
主人公は事の顛末を渕上さんに報告するだろうか？それとも黙っておくか？
もし後者を選ぶなら「主人公のDBサーバー設定ミス」という体裁にせざるを得ないので、主人公の責任になってしまう。
何にせよ、主人公には亀井君を止めて欲しい。
これ以上不毛な事をさせないで欲しい。
ななしんぼ
ほんとに仕組むとは思わなかったが、
人事異動から結構時間たってるのに権限そのまま残してるとか
この会社大丈夫なの？
LFR
本当に亀井君の社内テロか・・・。
主人公が正しく報告するとこんな感じになりますよね。
・インフラグループの上司懲戒
・インフラグループ全体に対して信用低下に伴う処罰（監査の厳格化）
・ITマネジメント課に対して教育不備による懲戒
・ITマネジメント課に対して事務処理不備による懲戒
・亀井君懲戒解雇
・配送センターに異動すべきと言った淵上さんの意見が正しかったと証明
・・・あれ？
淵上さんは無傷で、自身含めてお世話になった人の評価が死んでしまうので、結果淵上さんの評価があがるという意味の分からない状態になるようなｗ
どら猫ホームズ
次回はマシンルームで亀井くんの死体が
発見されると予想。
名無しPG
ダイイングメッセージは血で「Ｆ」・・・
wm
ダイイングメッセージは昔から「ヤス」と決まって（ｒｙ
それはおいといて、亀井くんにｿﾝﾅｽｷﾙｶﾞｱﾙﾄﾊｵﾓﾜﾅｶｯﾀﾅｰ
「なんか興醒め。」がぴったり。
実は、亀井くんが「F」の配下で、全ての悪役を受けるように密命を受けていた・・・ﾄｶﾅｲﾀﾞﾛｳﾅｰ
# どこかのマネジメント論に、叱られ役みたいなのを配置するように、とかあったもんで。
名無しさん
来週は切り立った崖の上に追い詰められた亀井君が動機を語りだすんですねわかります
saboten
超展開キター
こうして悪の面に覚醒した亀井君が、
世直し凄腕クラッカーとして義賊的な活躍を見せていく…わけないか。
Mr.Linq
まぁ、見守りましょう。どうせあたしら部外者だし。そもそもフィクションだし。
うとぅん
やはりDBのキャッシュ設定か・・・。
デモで突然起こるのは大抵そういうことだよな。
しかし、事故じゃなく故意なのは想定外だった・・・。
まぁまだ故意と決まったわけじゃないけど、
もし故意だとしたらあまりにガキすぎるね。
でじゃぶー
本当に死亡フラグ立ってるから困るｗ
命と引き換えなら渕上成功フラグは叩き潰されるんだろうが、なんだかなあ。
自殺未遂＆IT版慶安の変になって終わればそれはそれでハッピーエンド･･･か？
＠ｗ＠
穴予想として、渕上マネージャが亀井君を心の中で相当嫌っていて、亀井君をクビにするために仕組んだ罠だった！とかだったりして。
昔々のエンジニア
固定のＩＰアドレス？
ＤＢ接続の関係なのかな？
こういうのは古いやり方じゃないの、と Old Time Worker が聞いてみます。
ご存知の方お願いします。
人事異動したのにアカウント＆権限がそのままはヤバイよなぁ。
管理面の問題だと捉えられてしまう。
人事部長同席のデモだから、最終的な責任はふっちーにまで来る。
さて、このサボタージュの容疑者・亀井はいま断崖上にいるのか、それともアリバイがあって、真犯人は他に居るのか･･･
スリルとサスペンスの「方程式」。
背中に冷や汗が、つめた～いナ。
昔々のエンジニア
固定のＩＰアドレス？
ＤＢ接続の関係なのかな？
こういうのは古いやり方じゃないの、と Old Time Worker が聞いてみます。
ご存知の方お願いします。
人事異動したのにアカウント＆権限がそのままはヤバイよなぁ。
管理面の問題だと捉えられてしまう。
人事部長同席のデモだから、最終的な責任はふっちーにまで来る。
さて、このサボタージュの容疑者・亀井はいま断崖上にいるのか、それともアリバイがあって、真犯人は他に居るのか･･･
スリルとサスペンスの「方程式」。
背中に冷や汗が、つめた～いナ。
昔々のエンジニア
わぁ、恥ずかしい。
同じコメントを二回書き込んでしまった。
申し訳ない。
まさと
> 昔々のエンジニアさん
> 固定のＩＰアドレス？
DHCP かもしれません。
DHCP サーバが MAC アドレスを見てリースしていたら、亀井くんの PC の登録を消していない限り、以前と同じITマネジメント課用のアドレスを取得できます。
（22）（23）を読み返すと、亀井くんがとばされるまで数日しかたっていません。異動に伴う事務処理が徹底しなかった可能性もありますし、忘れていても無理ないのでは。
へろへろ
>こうして悪の面に覚醒した亀井君が、
>世直し凄腕クラッカーとして義賊的な活躍を見せていく…わけないか。
ウシミツ・アワーに
「ドーモ、フチガミサン。ディービーエー、デス」
ですね、わかりま(略
Fu
あぁ本当に亀井君なのか...？
いやいやまだ主人公の主観と状況証拠だけだ！ と悪あがきしておこう。
しかしまぁ主人公だめだめですねぇ。
デモ環境を直前まで完成させていなかったことが最後の砦をなくしてしまっています。
動作未確認環境でデモをしなければ、たとえ亀井君が何かしでかしても発見できたというところは教訓です。
主人公はまだそこらへんに気が付いていないことになっているようですが....
最期までにはきがつくのか、そのまま運が悪かったと成長せずに終わるのか...
あぁもう 明日次ＵＰしてください。
elbereth
なんでそんなに重複チェックするんだという、どうでもいい所が気になって仕方がない。
まさと
> Fu さん
> デモ環境を直前まで完成させていなかったことが最後の砦をなくしてしまっています。
前回の主人公と渕上さんのやりとりを読むと、渕上さんの指示に原因の一端がありませんか?
>（前略）デモで使うのは、テストデータですか？」
> テストデータは、氏名や住所をでたらめに置き換えた200人ほどのデータで、過去の勤怠データも2年分にしてある。
> 「いや、本番データで行く。本日時点の旧データから、再作成しておくように」
その後の主人公の作業手順を見ると、「本日時点の旧データ」＝「（デモ前日の）終業時間後に〆たデータ」のように受け取れます。
（こういうデモ用データ準備の仕方はありなんでしょうか?）
昔々のエンジニア
＞まさとさん
素早い解答ありがとうございます。
そうだ、DHCP だった。
MACアドレスで固定IPアドレスを振り当てるのは、やはり管理者用途でしょうか。
主人公も「それらをそのままにしておいた自分のうかつさにも腹が立ったが、誰がこんなことを想像するだろうか。」とほぞを噛んでいますね。
デモの前日っていろいろ確認の為に何故だか夜遅くまで残ったものです。
翌日、眠くてだるくて。
んーー、サボタージュとしても、あまりに稚拙な手段では？
明らかな業務妨害だから、懲戒処分の対象になってしまうかもしれない。
本当に容疑者・亀井の仕業なのかなぁ？
次回「断崖の上」ですかね？
よっしー
＞elberethさん
重複チェックは、確認画面表示時とInsert文（またはUpdate文）発行直前の２箇所だけですよね？最低限必要ではないでしょうか？
まさと
> elbereth さん
> なんでそんなに重複チェックするんだという、どうでもいい所が気になって仕方がない。
前回、↓のように語られていた現行版の重大バグを含めた対策じゃないでしょうか。
> 渕上マネージャが説明しようとしているのは、年次有給休暇の残日数を自動的にチェックする機能だった。現行版だと、年休の残日数が3日しかないのに、画面上では4日間以上を年休として指定することができてしまう、という重大なバグがあった。上長が矛盾に気付けば変更を指示することができるが、忙しい部門だとスルーされてしまうことも多い。そして、翌月の始めに前月分の勤怠表を出力して、年休残日数がマイナスになっているのを発見することになってしまう。これが年に数件は発生していて、そのたびに人事部門はつじつまを合わせるのに、大変な苦労を強いられていた。
ななし
＞少し迷った末に、あたしはコートをつかんで、ITマネジメント課を出た。エントランスを出るときには、小走りになっていた。
主人公は何処に行く気なのでしょうか。
間取りは不明ですが、亀井氏が居るマシンルームに行くのに防寒としてコートは必要だとしても、エントランスを出る必要はあるのでしょうか？
としろう
これが本当に亀井君の仕業だとすると大変残念です。
ちょっと調べればバレバレになる方法でこんな嫌がらせしても
最終的に渕上氏を喜ばせるだけと言う事が理解できなかったか。
現インフラメンバーや磯貝氏・主人公全て更迭の為、渕上氏の仕組んだ自作自演
ちょっと前に疑いだけで糾弾していた件から、
ろくな証拠も無しに亀井君ごと切り捨てる罠だったのか。
このままではいろんな意味で釈然としない結末へ向かいそうで嫌だな。
keeper
ななしさん>
少し前の棚卸しの回で、
>マシンルームは、ITマネジメント課がある事務棟に隣接した、工機管理棟の2Fにある。
となっているので、別の建物ってことでしょうね。
たぶん、つながってないので、一度、外に出る必要があるんでしょう。
k
仮に亀井の仕業だとして。
渕上式管理手法？彼の人格そのもの？の最大のデメリットは「要らぬ逆恨みを買う」、これに尽きますね。
ただ、一社に一人ぐらいはこういう人が居るといろいろ便利そうですね。
「変革」を起こしたい部署に放り込んだりなんかして。
二人以上は要らないと思いますが。ｗ
MM
オイラは、意外と磯貝課長があやしいと思うｗ
亀井君は、直情径行型ではあるが、姑息な手段を使っていやがらせするタイプでは、ないようなキャラ設定。フッチーに恥をかかせたところで、自分の評価が上がるわけではないこともわかってるだろう。
それよりかは、磯貝が、実は内心でものすごくフッチーに怨みを持っていたというほうが、話としてはすっきりする。
Fu
まさとさん
＞前回の主人公と渕上さんのやりとりを読むと、渕上さんの指示に原因の一端がありませんか?
あります。
先週のコメントにも書いたと思いますが、渕上マネージャにしてはつめがあまかったなぁと感じています。
（ここまで完璧にするとデモで失敗する余地がほとんどなくなるので、あえて作ったミスなのかもしれません）
ＭＭさん
磯貝課長...
ダークホースですねぇ。
ここにきて亀井君に罪をかぶせてとか、裏でを引いているとか...
推理小説になってしまうので、あまりうれしくない展開ですねｗ
主人公がマシン室につくとそこにはＬＡＮケーブルを抜いて高らかに笑う亀井君がなんていう結末はやめてほしいなぁと切に願う次第です。
さてさて、この生々しい展開がどのような結末になるのか...
elbereth
本筋とは関係ないんだけど。
> よっしーさん
unique constraintを付ければ、両方いらないですよね？
という俺の理解が何か間違ってるのかが気になって気持ち悪い。
> まさとさん
多分、文中のロジックは、休暇区分マスタメンテナンスの話だと思います。チェックしてるのも、名称の重複だし。
BEL
>elbereth さん
>unique constraintを付ければ、両方いらないですよね？
同感ですね。
マスタメンテなんてガンガンアクセスされるわけじゃないんだから
一覧getしたやつを保持しといて入力内容確認時はそれと比較してチェック、
最後のINSERTまたはUPDATEの時に重複したらそれはエラーでいいと思います。
というか、休暇区分なんていろんなとこで参照されるだろうし
逐一SELECTしないで更新がない限りはメモリにキャッシュしとけばいいのに。
まだ亀井君が犯人て決まったわけじゃないんですよね。
犯人だとしても渕上さんを困らせようと思ったかは不明。
とはいえ、回のまたぎはストレートなことが多いからな。
昔々のエンジニア
＞磯貝課長
このデモの件の黒幕なのでしょうか。
主人公はとりあえず亀井君のＰＣを確保して、デモ終了まで彼を見張らなければいけません。
しかし、亀井君はＰＣを持っていないのだった。
「どこにあるのよ」
「昨日、磯貝課長が来て、部署が変わったから返してくれって･･･」
がーーーん！！
「課長、これは一体どういうこと･･･」
「･･･取締役会議からの指令だよ。
･･･渕上さんにこれ以上居てもらっては困る、ということじゃないのかな」
あたしは二の句が継げなかった。
社内の政治力学にこれ以上関わってはいけない、と脳の隅で囁きかける声がした。
これじゃあ、ＩＴラノベじゃないよなあ～
fgnplo
えっこれラノベになるんですか
ITラノベなんてなれるSEぐらいかと思ってました
疑問
>というか、休暇区分なんていろんなとこで参照されるだろうし
>逐一SELECTしないで更新がない限りはメモリにキャッシュしとけばいいのに。
更新されたかどうかはSELECTしないとわかんないんでは？
ぽいう
一番のファインプレイはムツミさん。
ムツミさん vs 亀井くん。
TT
実際のソースコードが見えないので自分の経験からになりますけど、こんな感じでチェックを入れるよう言われることは案外多いですね。
1つ目のチェックはまだDBに投入しない入力内容確認の時点で重複があるかどうか確認するためだと思います。
2つ目はなんともいえませんが、結構INSERTやUPDATEで異常を出すのを嫌う構成が多く、その前に明示的にチェックを入れて引っ掛けたりするのでそれじゃないでしょうか。
people
>elbereth さん
>unique constraintを付ければ、両方いらないですよね？
>BELさん
>最後のINSERTまたはUPDATEの時に重複したらそれはエラーでいいと思います。
insert してみるまで、エラーかどうかわからんというのは、ちょっと乱暴な作
りではないですかね。
昔、別の会社が作ったシステムで、エンドユーザが使う画面なのに、エラーメッ
セージが「ORA-XXXXX」しか出ないという超不親切なやつがあったっけ。で、い
ちいち、連絡票書いてシステムに連絡しないと、重複だったのかどうかすらわか
らないという。
people
>2つ目はなんともいえませんが、結構INSERTやUPDATEで異常を出すのを嫌う構成
が多く、
>その前に明示的にチェックを入れて引っ掛けたりするのでそれじゃないでしょ
うか。
たぶんですが、確認画面から実際の登録処理までの短い間に、他の人が登録しちゃってないかどうかをチェックするためでしょうね。
映画館のチケット販売でも、選んでボタンを押すまでの間に、他に取られてしまって悔しい思いをすることがたまにあります。
elbereth
> peopleさん
> insert してみるまで、エラーかどうかわからんというのは、ちょっと乱暴な作
> りではないですかね。
PostgreSQLのデフォルトの分離レベルはリードコミッティドなので、重複チェックOKでINSERTしてもコミットでで重複エラーになる場合がありますね。つまり、やるだけ無駄なんです。
それに、チェックしてからINSERT/UPDATEというやりかただと、全体をトランザクションに入れる必要（入れないのなら、さらにチェックの意味がなくなる）があり余計なロックが必要になったりします。constraint方式だと、処理がアトミック（一回の処理で全部が終わる）なのでトランザクションにする必要がありません。
> 昔、別の会社が作ったシステムで、エンドユーザが使う画面なのに、エラーメッ
> セージが「ORA-XXXXX」しか出ないという超不親切なやつがあったっけ。
constraint違反の場合はその名前がわかるので、日本語のエラーメッセージに変換するのは簡単です。
さそうたける
うーん、INSERT/UPDATE時のユニーク制約違反で重複チェックするようにすると、
Exceptionを発生させるコストが高いので、
Exceptionを発生させない低コストな方法(=事前にSELECTして確認)を取ってるのかな？
くらいしか思いつかない。
でも、休暇区分マスタって小規模なテーブルっぽいし、
そんなに目くじら立てるほどの性能差が出るとは思えないので、
いきなりINSERT/UPDATEでもいい気はする。
単に、Exceptionを発生させないやり方が規約になってるとか、癖になってるとかなのかも。
さそうたける
>でも、休暇区分マスタって小規模なテーブルっぽいし、
>そんなに目くじら立てるほどの性能差が出るとは思えないので、
あれ？
小規模なテーブルの方が事前のSELECTにかかるコストが低いから、
Exception発生させる場合と比べて、性能差が顕著に出るのか。
elbereth
> さそうたける
> Exceptionを発生させない低コストな方法(=事前にSELECTして確認)を取ってるのかな？
> くらいしか思いつかない。
ひょっとしたら、このやり方が何かの言語/フレームワークのデファクトスタンダードなやり方なのだろうかとモヤモヤしてます。
ちなみに、今俺がやってるそこそこの規模の業務系Webアプリでは、重複チェックは一切ありません。つか、マスタメンテ画面で画面遷移しないし（全部Ajax）。
pec
実は渕上マネージャが事前に変更しておいて、デモ前に確認しなかった日比野さんの責任として部署移動させるための罠とか。
>亀井くんは渕上マネージャのことがよく分かっていない。そんなシーンは白昼夢でしかない。
デモでの影響も少ないと踏みつつ、サーバーへのログイン履歴とかも消して誰の犯行かも隠蔽しつつとか。亀井さんへ疑いも向きますし。
全然別の通りがかり
INSERTの直前のSELECTは、重複チェックという意味もありますが、実際には、UPDATEの前のロック取得という意味だと思いますよ。
SELECT - FOR UPDATE NOWAIT無しでUPDATEかけるとロック待ちで帰ってこなくなる時がありますから。
よっしー
＞elberethさん
画面繊維しないAjaxなら、Insert実行時の例外処理で問題ないかもしれませんが、今回は「確認」画面があります。確認画面を表示する時点（Insertはまだ）で重複エラーを判別できるのに、実行するまでエラー表示しないのは、私は好みませんね。
よっしー
＞私は好みませんね。
なんて、えらそうな書き方しちゃいましたが他意はありませんのでご了承ください。
ysk
前回の話からすると日々野さんも亀井君から恨まれてる可能性だってあるんですよね。
そのときの状況を知らないわけだろうし、もはやITマネジメント課には敵しかいないと思ったとか。
タイトルの Daydream Believer って亀井君がムツミさんに歌っているようにも見えるし。
さそうたける
>前回の話からすると日々野さんも亀井君から恨まれてる可能性だってあるんですよね。
ありえますねー。
亀井くんから見れば、主人公は「保身のために渕上マネージャーに媚を売って、愛するムツミさんのいるホライゾンを切った裏切り者」ですからねー。
elbereth
うーん、そもそも確認画面なんか害悪派な俺なので、話があわないのかな。
重複チェックが必要だという人は、主キーにナチュラルキーをつかうときに、やはり主キーの重複チェックをinsertの前に行うのだろうかという疑問なんかもあるんですが、この話はこれくらいで・・・
BEL
>疑問さん
>>逐一SELECTしないで更新がない限りはメモリにキャッシュしとけばいいのに。
>更新されたかどうかはSELECTしないとわかんないんでは？
もちろん、更新された場合はキャッシュを削除(or最新に更新)する前提です。
ただ、これはマスタの更新がこのアプリケーションからのみである場合にしか
実現できませんし、APサーバ自体がロードバランシングされている場合は
memcachedのような仕組みを使う必要がありますが。
>peopleさん
>insert してみるまで、エラーかどうかわからんというのは、ちょっと乱暴な作
りではないですかね。
画面初期化時に一覧getしているのでそれと比較すれば十分かなと思ったのです。
そうすれば重複エラーになるのは、メンテ画面を複数人が同時に開いて、
かつ、新規登録(or更新)で同じ名称を指定したときという、限定的なものです。
(ただ、私はこの"一覧get"というのを誤読している可能性はありますが)
一方、マスタメンテ画面なんてそうそう使われないんだから
何回かSELECTしても大して負荷に影響はない、という考え方もできますけどね。
今気づいたけどこのロードバランシングってSELECTのみ切り替わって
UPDATEとかのときは切り替わらないのね。
それでよくムツミさん3回に回の正体わかったな。
>elbereth さん
>うーん、そもそも確認画面なんか害悪派な俺なので、話があわないのかな。
私も、ajaxなどが普通になった今は特にそう思います。
確認画面から戻る動作があったりすると複雑になりますしね。
keeper
>今気づいたけどこのロードバランシングってSELECTのみ切り替わって
>UPDATEとかのときは切り替わらないのね。
>それでよくムツミさん3回に回の正体わかったな。
pgpool-II のロードバランスは、select文はロードバランスするけど、updateとかinsertとかdeleteはそうしないんじゃなかったっけ。更新系の場合は、全てのノードに同じ文を流すので、3回に1回だけ遅くなるのではなく、毎回遅くなるんだと思います。それとも、非同期だったか、ちょっとあやふや。
keeper
>>うーん、そもそも確認画面なんか害悪派な俺なので、話があわないのかな。
>私も、ajaxなどが普通になった今は特にそう思います。
>確認画面から戻る動作があったりすると複雑になりますしね。
Teeda フレームワークは、そのへんはかなり楽ですね。
ボタンのidを、jumpXXXXXX とすれば、戻ってくれるし。
昔々のエンジニア
業務APから主に参照するだけのマスタのメンテナンス画面は、いろいろ凝った造りや工夫をするより、運用面から考えて、アクセス権限でユーザー・アカウントを絞り込む方が何かとベターだと思います。
Insert や Update のエラーは例外処理で、エラー内容が判明する＆APが強制終了しない、ようにしておけば事足りると。
リレーショナルDB以後、そもそも初期データ自体、LOAD 処理で造って、メンテナンス画面で一覧確認するだけ。
メンテ画面でデータの追加って、新規データ以外はありえないし、新規データの発生もめったに無い。
ふっちーではありませんが、ここはコストをかけるべきところではないと思います。
ただ、キャッシュしちゃえばどーよ？、というのは、変更が即座に反映しない、というデメリットがあるので、個人的には、AP は随時 Select を行うことにして、DBサーバー側で、頻繁に参照される比較的小さなテーブルだけ、メモリ・キャッシュする（適時に置き換え可能という条件のもと）に賛成票を入れます。
えーと。
マスタと呼ばれるなかには、業務系のもの（取引先とか）があります。
これは日常業務で追加と変更が必要なので、すみやかな業務の遂行を第一に、データの保全を第二に考えて、設計します。
でも、個人的には、組織変更に伴うデータ移行とか個人履歴とか、勤怠処理システムとその他の社内システムとの整合性、データ連携のタイミングとか、むしろそちらに興味が湧きます。
このラノベの「勤怠システムのリプレイス開発」ではフォーカスされていませんが、勤怠システム⇒給与計算へのデータ連携とか、人事異動・昇格・降格⇒勤怠システムへの反映とか、いろいろと興味津々です。
いや、長々と失礼つかまつった。
FAR
>pgpool-II のロードバランスは、select文はロードバランスするけど、updateとかinsertとかdeleteはそうしないんじゃなかったっけ。
>更新系の場合は、全てのノードに同じ文を流すので、3回に1回だけ遅くなるのではなく、毎回遅くなるんだと思います。
>それとも、非同期だったか、ちょっとあやふや。
マスタスレーブモードなら更新系はマスタのみに発行して、レプリケーションモードならマスタとスレーブ両方に発行。
SELECTはマスタ、スレーブどちらかに発行するようにするとか。
分散ルールを決めて分散配置したデータを個別取得し、pgpoolで結果をまとめるようにするとか。
pgpool2でレプリケーションしてるなら同期だったような。
postgresqlなら同期か非同期どちらか選択できたかな。
ここでは、pgpool2はマスタースレーブモードにして、postgresqlでストリーミングレプリケーションしていると思います。
K.Oumi
しかし、書かれている程度の問題を事前になんともできないっていう・・・
環境確認すらおざなりだってだけじゃないか・・・
こんなデベロッパー達と仕事したくないなぁ・・・
よくもまぁ、このヒドイデベロッパー使って、デモまでこぎつける事ができたもんだ・・・
どちらかというと、マネージメント云々よりデベロッパーの質の方が気になってしまうなぁ。
こんなのが「普通」なのかねぇ・・・
まぁ、現実には沢山いるのだけど「普通」にしたくないものです。
作者さんは何を問いかけたいのだろう・・・
名無しSE
かなりどうでもいいことなんだけどここでみんなが言ってる「アジャイル」ってアジャイル開発手法のことだと思ってたんだけど違うのか？
仮に経営用語だとしてもForbesの記事を読んだ限りは発端はソフトウェア工学側で、経営学的にもそこからいろいろ学べるよって書いてある気がするが。
名無しSE
うむ、コメントつける記事間違えたわ…すまない。
sa
・ムツミさんが首謀者
・亀井君が実行者
なんてねー
0x86
主人公が実は健忘症。
これだ。
Z
今回、環境を構築して確認するのは主人公の役目でデベロッパー（ホライゾン、サードアイ）の役目じゃないですよね。
hoge
>0x86さん
>主人公が実は健忘症。
叙述トリックですね、わかります。
物語は主人公の主観で語られてますが、客観的に全く違っていると物語がひっくり返りますなぁ。
ななしんぼ
>Z
そうですよね。K.Oumiさんは何が言いたかったんだろう？
ななしんぼ
Zさん敬称わすれてました。すみません。
fuga
デベロッパ（開発者）
主人公もデベロッパじゃない？
たもつ
K.Oumiさんは複数形で「デベロッパー達」と表記されているので
主人公だけを指しているわけではありませんね
Fu
K.Oumiさん
皆さんがコメントしている通り、デベロッパー達が誰を指しているか定かではありませんが...
といっても主人公をはじめ、サードアイ以外は、「記録」「段取り」という概念を持ち合わせていないので、ダメダメという指摘はその通りだと思います。
「段取り９割」、「記録のない作業は趣味」
です。
渕上マネージャーも記録に対してはいろいろを頑張っていましたが、デモの段取りを主人公に任せて最終確認しなかったところは詰めが甘かったですねぇ。
Z
みんな環境確認のつめが甘いとはいうけど、普通に主人公もデータ作成して動作確認はしてますよね。そうであれば、当日にもう一度動作確認しないというのもそんなにおかしくないような気がします。
バッチも何も動いていないなら内部の人間が工作でもしない限り何もおきないわけなので、安心しきっててもしょうがないと思うんですが、そこまでやるべきでしょうか?
Fu
＞Tomcatのログで起動を確認した後、ブラウザでAPサーバのログイン画面を開き、ログインしてみた。問題なくメニュー画面が表示される。勤怠状況確認画面をクリックしてみると、24日の出勤までの一覧が正しく表示された。問題はなさそうだ。
これは動作確認ではないです。
＞デモ環境の最終設定が残っている。
とあるので、プログラムのロジックという観点ではデモの事前確認は終わっていますが、デモ環境という観点では確認が終わっていません。
故に、デモ環境作成後に確認が必要となります。
この確認を実施しないと、デモ環境作成時のミスを発見できません。
Z
確かにFuさんの言うとおりですな・・・
画面一枚だけですね。
アプリケーション側は確認できていても、DBの接続先を本番に変更して、そのデータでの確認は確かに実際の画面でいうとログインの後が1枚だけですね。
これは大事なデモの前としては十分な確認とはいえないですねえ。
最低限の導線確認（チェックリストに基づいて）はやらんといかんです。
見通してました。すみません。
私もよく本文を読んでないという意味では「ダメなデベロッパー」ですわ。
Fu
Ｚさん
そういうことです。
主人公と同じ罠にはまってましたねｗ
ここらへんは、日々本番環境相手に１クリックで業務影響を及ぼすような仕事をしていると勝手に目が危険信号を出しよります。
もっと極論を言うと、デモという目的の前にはプログラムの動作はどうでもよくて、決まった筋書きで問題なく動けばその筋書きを外れた場合にどんな問題が起きてもかまわないわけですｗ
まぁ質疑応答での説明等、そうはいかない場合もありますが...
なので、Ｚさんの認識のとおりデモ環境を作成した後、必ずデモと同じ操作を実施する必要があったわけです。
この小説は主人公の知っていること、確認したことしか書かれていないので、うっかり読み飛ばすと伏線を見落とします。
たぶん、私もまだまだ見落としています（いくつか後で読み返して気がついた伏線もあります）
亀井君が設定を変えたというのもまだ推測でしかないわけです。
（確度は高そうですが...）
実はデモ環境を作成する作業の中で主人公がやらかした可能性もまだ残っていたりします。
（主人公が覚えていない作業が小説に書かれていなかったら、こっそり伏線として忍ばされていたり...）
こうやって書いていると、リーベルGさんのロジック作成能力のすごさに感心しますね。
tui
そもそも、亀井君が地雷を仕込んだならタイミングもまだ分からないので、気が付けるタイミングも分からないし、
渕上さんや、主人公が行ったテストの詳細も書かれていないので、なんとも言えないと思います。
「渕上さんや、主人公が行ったテスト」が本番機に繋いでのテストであれば、当日の確認内容が、ログイン画面までで、十分だった可能性もないですか？
さとる
このタイトルで忌野清志郎がでてこないなんてっ！！！！
まぁ
この状況だと、鬱展開しか想像できない...
遅延工作は謎のクラッカーの仕業で、主人公がサーバールームに
駆けつけてみると、亀井君と真犯人が取っ組み合いの最中だったとか...
真犯人の名前を出さないと苦しいか...
.........................................
「日比野くん！」
抑え気味だが、やや責めるような口調に、あたしは、あわてて
磯貝課長へと向き直った。
「デモの設置で疲れているのは分かるが、居眠りとは何事かね？」
はっとして、壇上に目を向けたそのとき、渕上マネージャの
よく通る声が響いた。
「では、新勤怠管理システムのデモを始めます」
だめか...
更新されていないのをみて、あぁ、今日は休日なんだと認識したわけですがｗ
イロイロな意味で犯人は、亀井君以外の人を望む声が大きいですね。
私もその一人ですがｗ
設定したのは亀井君でも、悪意じゃなくて、別の理由であって欲しいなぁと願うばかりです。
でもって、このモヤモヤは明日までの我慢なんだろうか？
それとも来週までの我慢なんだろうか？
気が付けば週１連載に慣らされている自分がいるｗ
BEL
私は亀井君が犯人でもいいんですが、テロよりは何らかの種明かしが欲しいです。
亀井君以外の方が話が広がって面白いですが。でもこれって何話までなんだろ。
4/30のときが5/1公開だったので明日公開なんじゃないでしょうかね。
名無しPG
そういえば祝日のときは翌日更新だっけ
待ち遠しい＞＜
Fu
＞「渕上さんや、主人公が行ったテスト」が本番機に繋いでのテストであれば、当日の確認内容が、ログイン画面までで、十分だった可能性もないですか？
その可能性はないです。
なぜならば、「渕上さんや、主人公が行ったテスト」がどの環境でのテストであっても、
＞デモ環境の最終設定が残っている。
とあるので、テストした環境とデモの環境は似ているかもしれませんが同じ環境ではありません。
デモ環境の最終設定でのミス等の要因でデモが失敗するリスクがあります。
そして、
＞亀井君が地雷を仕込んだならタイミングもまだ分からないので、気が付けるタイミングも分からないし
という点ですが、たとえば亀井君が何かを実施したと仮定した場合、これは上記のデモ環境での最終確認では防げないのはご認識のとおりです。
なぜならば、デモ環境での最終確認は、最終確認後にその環境を変更しないというのが大前提となるからです。
そして、亀井君の行為を防止するためにはどうすればいいか...
あるべき論だけを言うと、「関係者以外に権限を与えない」
となります。
ただし、この小説の場合、それを徹底するのは事実上不可能です。
なぜならば、亀井君は確かにまだ権限を持っており、主人公はその権限をはく奪するのを失念しています。
これは失点ではありますが、社内ＳＥという状況からいって、即日はく奪できる仕組みを持っている会社はあまりないかと思います。
さらに言うと、亀井君の異動先は、同じ部署であり、サーバそのものに物理的にアクセスできる立場を維持しているようです。
その気になればまだまだ何でもできます。
デモ中にＬＡＮケーブル抜くとか、サーバの電源切るとか、ＤＢサーバに負荷をかけるとか...
とはいうものの、亀井君のしわざという結論だったとすると ちょっとへいぼーん かなぁと^^;