みなさん、こんにちは。昨年はコロナに倒れておりましてアドベントカレンダー2年ぶりの参加です。
最近はレガシーな巨大アプリの保守開発に取り組みつつCI/CDもやっています。今日はCI/CDに取り組む中で思う、全エンジニアに個人的にお勧めな手軽にできる活動を紹介しようと思います。
前段
懐かしき、かつての開発現場
ちょっと昔話をします。
かつてCOBOLソースの修正をするときは、自分の手元のテキストエディタで修正して(入力補完なんて存在しないし構文エラーも検出されない)、コンパイル環境のUnixマシンにアップロードして、ターミナルで繋いで、コマンドでコンパイルしていました。
手元ではコンパイル通るか分からないまま書いているので、コンパイルエラーがしばしば発生しました。コンパイル通ったら動作確認して、できたソースは自分でソース管理のリポジトリにアップロードしたり、評価環境に配置したりしていました。
この頃はレビューも印刷物ベースで実施されており、紙にCOBOLのソースを印刷してソースコードレビューを行い、レビュー時と違う差分が提出されてないかを評価担当者が目検してたりしました。10年ほど前の話です。
ほぼ手作業でやってるので、ソースコードファイルをマシン間で転送する際に文字化けする問題の対処だったり、コンパイル通らない原因の対処だったりを自ら対処していました。
その後、COBOLをスーパーハイパーウルトラ頑張ってJava化し、当たり前にIDEを使ってコード書きながらビルド・デバッグするようになり、コードもgit管理するようになり、レビューをMRやPR上でするようになり、徐々にビルドや各種チェックを自動化して今に至ります。
自動化していった結果どうなっているか
改めて過去と比べると、めちゃくちゃ便利になった！！これは間違いない。無駄な作業が減った上に、各人の手作業工程での作業漏れやバラつきも最低限のラインは揃えらえるようになったと思います。
一方で、何がどうなって修正したものが出荷されていっているのか、ブラックボックス化も進みました。（更に自動化の仕組みの中にも技術的負債が蓄積し・・・という話は今回は省略）
そしてエンジニアが「何か自分の入れた修正が環境に適用されてないんですけど」とか「何かチェックで赤くなってるけど無視しちゃった」とか「急いで暫定モジュール出したいのにビルドが終わらない」ってCI/CDチームやら関係者らに言う事態が発生する時代の到来です。
ちがう、そうじゃない！！！私たちが作りたかった便利な世界はこれじゃない。
せめて、どうしてそうなっているか知ろうとして欲しい。
・・・マインドの話はきっと他に沢山のポエムがあるかと思うので、すぐにはじめられることの話をします。
いますぐにできること
「よく分からないけれども何か動いている(あるいは動いていない）」
「なんかエラーっぽいログが出てるけど、動いてる…？」
CI/CDの仕組みに関わらず、自分以外の誰かが開発してきたアプリの保守に関わる者であれば誰しも経験する可能性があることだと思います。
理解のために、ドキュメント読んだり、先輩の話を聞いたり、AIに聞いてみたり、色々な選択肢があると思うのですが、その選択肢に入れていただきたいのが ログを眺めてみること です。
自動化スクリプトにしろアプリケーションにしろ、あらゆるものはログ出力があります。無いことは非常に稀です。
そのログを読みましょう。
ログリーディングの心構え
全てを理解できなくても構わないけど、少しずつ仲良くなりたい、という気持ちで向き合います。
- いつ・どこ・何から書かれたログなのか
- 何をしようとしているのか
- どういう順番で処理しているのか
を推測しながら、とにかく読んでみましょう。
必要に迫られて調べたり、大量に読んだりする内に、推測が少しずつ確証になり読めるようになっていきます。
トラブル発生時に読む
正常時のログと異常時のログを比較してみましょう。
どこから違いが生まれているかが、原因調査の第一歩になります。
異常時のログにERRORとかFailedとかExceptionが出ている場合はラッキーです。
確実とは言えませんが、それが原因な可能性が割と高いです。
世間一般的な仕組みを利用している場合には、ググると情報出てくることも多いです。
CI/CD関係のトラブルにおいては、ログを見て、ここに問題がありそうだがどう思うかという形でCI/CDチームにご相談いただくと嬉しいです。
CI/CDに限らず、相手を知ろうする歩み寄りの態度に対しては、きっとエンジニアは温かな態度になると思います。
つまり、一緒にトラブル対応をする仲間を得やすくなるってことですね。
すごい、ログ読むといいことがありそう！
常時にも読む
さらにお勧めなのは、困ったときに限らず、ログ出力を目にする機会があればログを眺めてみることです。
こういう技術をここで使ってるのか、とか、このコマンドでこんなことができるのか、等の技術的なキャッチアップもできます。
だんだん慣れてきて、このタイミングでいつもこういうログが出る、これは普段は目にしないログだな…というのが分かるようになります。近所のお散歩みたいな感覚です。
この状態になると処理への理解が進んでいるはずです。
また、何やら時間がかかってる処理がある等にも気付くようになります。
変化のいち早い察知や、問題箇所の発見に繋がり、処理や実行環境の改善になることもあります。
すごい、ログ読むといいことがありそう！！
ログについて語ろう
沢山のログを読んでいると、だんだんログ出力のあるべき姿について語れるようになってきます。
こういう情報を出して欲しい、ログレベルはこうすべき、ログの保持期間は～、ログの参照性を高めるにはどうしたら、まで考えが至ってくるはずです。
読み手から書き手へ、更に流通経路まで考えられる、ログの設計者としての素地がいつの間にか形成されます。
ログ出力はアプリケーション開発の中でも必須な要素です。
作成者はやはり利用者のことが分かっている方がいいものができます。
つまり開発で設計やコーディングする時にも活かせる体験が自然とできている状態になります。
すごい、ログ読んで語るといいことがありそう！！！
まとめ
アプリケーションのログでも、ビルドスクリプトのログでも、まずは読んでみましょう。最初はよく分からなくても、少しずつ理解していけばいいのです。
ログを読むと処理への理解が深まり、仲間が増え、開発者としての技術力がアップします。いいことだらけです。
ログを読みたくなってきたあなたにも、いいことが沢山ありますように。
そしてログを読んだ上での会話がエンジニアの間でされることが増えますように。
ログリーディング is fun!