オークファン Advent Calendar 2019 21日目担当@kei75です。
昨年の「オークファン Advent Calendar 2018」では運用監視についてちょっと真面目な記事を投稿しました。
今年は何の(運用の)話を書こうかなぁと思っていたら、記事公開まで1週間をきってしまったので、
慌てて記事をしたためている今日この頃、皆様年末いかがおかごしでしょうか。
自己紹介
2007年にネットプライスに入社して以来、情報システム部門、インフラ、開発と色々と渡り歩いてきました。
2018年10月よりオークファンに転籍になりましたが、やってることは相変わらずです(笑)
比較的レイヤーの低いところを得意としているエンジニアと自負しておりますが、「浅く広く」なエンジニアなので専門の方にはかないません。
というのは2018年までの自己紹介。
2019年4月にインフラチームのマネージャーを仰せつかり、素晴らしいメンバーに囲まれながら日々運用に励んでいます。
本番環境でやらかしたことを供養する2019冬～事件は会議室で起こってるんじゃない。現場でおこっt(ry～
さて今年は個人的に色々な事件が現場で起こる1年でした。
-
年明け早々にインフルエンザにかかり自分がダウン
- もちろん予防接種は受けていたけど、「かかるときはかかりますよ」と医者に諭される
-
年始から本格的に始めた都内某所から都内某所へのひとりデータセンタ移転で想定していないトラブルが続発
- CiscoとHUAWEIの間でLACPを使ってLAGを組みたかったのに、なぜか認識されない。なぜなんだ
-
春に、居酒屋で(元)部長から「MGRなんかどうっすかね～」と言われ冗談だと思っていたらホントだった
- しかも(元)部長は「あのとき居酒屋で話したじゃないですか～あはは～」いやいやちょっとまってよw
-
夏に、決済周りのトラブル対応で更にトラブルを上書きして死にそうになる
- 死にそうになったので神社にお祓いに行くも、八方除をするつもりが間違えて方位除をしてしまう
-
秋に、消費税対応作業を増税当日(10/1)にやっていたら、同じフロアのフリースペースで年度末締め会(?)が盛大に開催される
- しかしながらトラブル対応に追われ全く参加出来ず
-
師走に近くなったころに急にサービスリニューアルが決まり、想定以上のイレギュラー運用が多発する←Now!
- 更に年末に倉庫を引き払うことが決まり、年末の休みが無くなる←Now!!
もうね、駆け抜けるような2019年だったわけです。
ここでは書けないようなアレな内容も盛りだくさんなわけでして…。
それでもなんとか2019年を乗り切れたのは、同じ会社で働く皆さんのおかげでした。
改めてありがとうございました。(年末のご挨拶)
そんな2019年に区切りをつけ、来る2020に向けて新たな気持ちに切り替えるべく、
このアドベントカレンダーを真似して記事を書いてみることにしました。(爆)
もう見たときは既に埋まっていたのよね…。
みんなやらかしたことがいっぱいあるんだなぁ。(ｼﾐｼﾞﾐ)
ということで、部長のOKが出るか分からないけど(一応OKいただきました!よかった!)後世への道しるべと懺悔、ご迷惑をお掛けした全ての方への謝罪と感謝を込めて、この記事を贈ります。
供養したい夏の決済周りトラブル
何が起こったか(概要)
バッチで一括処理している与信処理(オーサライゼーション)がこけて、トラブル対応中にトラブルを上塗りしてしまい大惨事に…。
お客さまからも多数問い合わせが入ってしまい大事件となった。
あんまり詳しくは書けませんが、概要としてはそんな感じ…。
なぜ惨劇が起こったか
トラブルを上塗りした要因
与信処理用SDKがログを出すはずが、ファイルサイズが4GBを超えておりログが出力されていなかった
いつものトラブルだろうと思い、アプリケーションログを確認せずに再実行してしまった(アプリケーションログは一応出ていた)
再実行しても結果が変わらないのでおかしいと思い、とりあえずもう一度実行してみた
アプリケーションの実装がイケてなく、微妙なところでロールバックせずに落ちる(しかも例外で)
このようなエラーを検知する手段・手法が全く確立されていない
今まであまりトラブルになったことがない
細かいことを言えばもう少しあるのですが、事件が起こった要因は上記のようなことが挙げられます。
アプリケーションの実装が悪いという言い訳は出来ますが、これは運用側としては致命的なミスとしかいいようがありません。
弁解の余地無し。
二度と同じ悲劇を繰り返さないために
さて、上記の初動対応さえ間違っていなければ、この最初のトラブル(バッチがこけた)は大した問題にはなりませんでした。
要因から対策を導き出して、具体策に落とし込んでいきましょう。
与信処理用SDKがログを出すはずが、ファイルサイズが4GBを超えておりログが出力されていなかった
バッチはWindowsServer(NTFS上)で動いていましたが、ファイルサイズの制限はどんなOSにもつきものです。
そもそもこんなになるまでログローテーションもせずに動かし続けたことが最大の問題です。
適切にログローテーションを行い、大切なログがきちんと出るようにしておく
いつものトラブルだろうと思い、アプリケーションログを確認せずに再実行してしまった(アプリケーションログは一応出ていた)
論外w
アプリケーションログは必ず確認する
それに尽きる。
見ても分からなければ、分かる人に聞く！百聞は一見にしかず
再実行しても結果が変わらないのでおかしいと思い、とりあえずもう一度実行してみた
論外中の論外ww
アプリケーションログを確認したとしても、再実行には細心の注意を払わなければなりません。
そのバッチは、ほんとうに冪等性があるバッチでしょうか…。
書き換えたデータを再度書き換えてしまったら…
そのデータが実は後続処理に流れていて、失われてはいけないものだったら…
失われたデータを取り戻す手段が無かったとしたら…
再実行する前に、胸に手を当ててアプリケーションの仕様を確認するのです。
分かる人に聞く！百聞は一見にしかず(2回目)
アプリケーションの実装がイケてなく、微妙なところでロールバックせずに落ちる(しかも例外で)
これはまあ…運用側が悪いわけではないのですが…
ただ、そのような挙動をするアプリであるということは認識しているべきかと思います。
知っていれば、何が原因なのかを特定する手助けになるかもしれません。
運用側がアプリケーションを知らなくていいはずがありません。
いくら作業手順書があったとしても、知っているのと知らないのでは、運用業務には差が出ます。
アプリケーションを熟知する必要はありませんが、分かる人があれば分かる人に聞く！百聞は一見にしかず(3回目)
ちなみに私は、インフラエンジニアであり運用エンジニアですが、アプリケーションエンジニアでもあった(過去www)ので、
ある程度の挙動は把握していましたww
このようなエラーを検知する手段・手法が全く確立されていない
古いアプリや、開発した人間が既に居ないアプリケーションではよくある話ですw
ないものを責めても仕方ありません。
ないのならば、自らの手で作り出す、それが真の運用エンジニアなのです。
(そんなことはないというツッコミは野暮ってもんですよw)
もちろんトラブルのあと、データベースの内容をチェックして適切に処理が終わったかどうかを判定するための仕組みを作りました。
それ以降、似たようなトラブルがあっても、すぐに検知が出来て適切な対応がとれるように進化しました。
今まであまりトラブルになったことがない
トラブルなんてそうそう起こって良いものではありません。
ただ、全くトラブルが起こらないと、いざトラブルが発生したときに慌てふためき泣きわめき世界の終焉を感じながらコンソールを必死に叩くことになります。
事前に訓練が出来ていれば、落ち着いて対応することができるでしょう。
そこでこんな話↓(よそ様の記事w)
保育園にChaos Engineeringを提案した話
https://qiita.com/Mahito/items/2245429ce96027e27949
最近流行でもあるので説明などは他所へ譲りますが、このような訓練を日常的にしていればシステムの耐久性も上がり、安定したシステムになることでしょう。
(安定していれば運用エンジニアがいらなくなるわけではありませんよ)
さすが、これは当社ではすぐに実施することができないのですが、将来的にはぜひ取り入れていきたいと思っています。
まとめとして
長年運用をやっていると、気の緩みというものがどうしても出てきます。
常に本番環境を触っている、その先に大切なお客さまがいる、という認識を持って日々の運用にあたることの大切さを切に学びました。
色々な方にご迷惑をお掛けして本当にすみませんでした…。
運用という業務は、はっきり言って光のあたる華々しい業務ではありません。
例え評価されなくても、お客さまから多大なクレームを受けても、社内で孤独にトラブルと戦っていたとしても、そこにサービスがある限り必要とされていることを忘れずに、誇りを持って日々運用業務に勤しみたい、そう思う2019年(令和元年)の年末でありました。
なぜ運用があるのですか？そこにサービスがあるから
最後に
来年もがんばって駆け抜けますので、みなさん一緒に頑張りましょう。
また、スリリングな運用日常を常に求めているという心意気のある方がいましたらぜひ一緒にお仕事をしましょう！
よろしくおねがいします！