SRE に成る君に最低限の開発力を身に着けてほしい

はじめに

まず、はじめに皆さんへ言っておきたいことがあります。

このドキュメントの目的は皆さんをやる気にさせて一心不乱にコードを書きまくって新機能追加や改善をしてソフトウェアを開発していってほしいというわけではないということです。 もちろん、そうなってくれれば嬉しいですが気合が入ったからプログラムを急に書けるようになるわけではないのでそのような目的は一切ありません。また、この文章にはインフラエンジニアがコードを読み書きできなくて良いという意図はなくポジショニングトーク的にSREという単語を利用しておりますので何も言わないでください。

SREはそもそも、コードを書かなくてもよいエンジニアではない

SREとは、ITサービスの信頼性を高めるために、ITエンジニア（開発者）が信頼性向上のために行う設計やアプローチ、またはこれらを行うチームや役割を指します。

Google では、SREチームの50～60%は「Google のソフトウェアエンジニア」で、残りの40～50%は「正規のエンジニア『予備軍』だが、他のメンバーには持っていないスキルを持っているエンジニア(インフラ技術に特化した人材)」を選定しています。

そして、そのチームは自動化・省力化するために積極的にプログラムを書く。SREが「System Administrator」ではない最大の特徴は、システムの拡大に伴い、保守運用工数が正比例して増大することのないように、自分たちでプログラムを書いて積極的に自動化・省力化を行います。

が今更、そんなことを言うつもりはない。SREで大事なところはそこではない。大切なのは役割や役職としてのSREではなくSREのプラクティスであると思う。「SREの探求」でもそれは１言及されているので異論がある方は読んでから議論しましょう。

www.oreilly.co.jp

インフラエンジニアからSREになるということ

SRE　≠　インフラエンジニアという認識は皆さんにもあるとは思います。そもそも、開発力が皆無でコードの読み書きが選択肢になければ問題が起きた時に挙動を把握し続け、ログやメトリクスでとことん確かめていきます。何が起きてるか事実ベースで完全に外からの推論だけで把握するというのは難しい、もしくは不完全です。

コードを読めなければ問題を解決するのはいつも本当の偶然か、計画的な偶然か、もしくはそれらを超越した熟練者の直感によるものが多いです。もちろん、直感は素晴らしいです。なぜなら、熟練者の直感は問題が起きた時に直感で全ての問題を見つけて解決していくからです。それらは、高度で本人にさえ言語化不能で本当に超能力者みたいです。私はそのような能力をまだ持ち合わせていないです。が、問題は起きていて解決は迫られてます。直感を身につけるような時間はもう、残されていません。明日の朝にはこの問題を解決して納品しなければリリースに間に合わない。解決や期間的な目処は立てなければなりません。もし、解決方法もどれだけで解決するかも分からないとなればプロジェクトに関わるメンバーは不安になると思います。

自社開発のソフトウェアで、自社のエンジニアが書いたコードあればそのエンジニアか所属する組織への依頼をすれば良いでしょう。ですがSREは自社のソフトウェアだけではなくOSSと向き合っていることも多く不具合を気軽に相談できない場合も多いです。私に起こった不具合が設定値によるものなのか？ 実装によるものなのか？ を切り分けができなければOSSのIssue も出すことができません。ちなみに、有償サポートでは、その限りではないと思います(有償サポートがあるなら頼れ)。

ソフトウェアを読めることで、問題が起きた時にコードを読み尽くして、負荷試験や本番で挙動を把握し続け、ログやメトリクスでとことん確かめていけばシステムに対する解像度が上がります。プログラムをちゃんと読めて原因の特定、修正がコードレベルでできるようになるという選択肢は確実性を高めます。そのため、ソフトウェアの開発経験がないエンジニアのためにOJTに開発経験を追加してそういった素地を最初に作ってもらいたいと思っています。

システムへの解像度をあげてエンジニアとしてのレベルを上げる

問題が起こったらログやメトリクスから情報を収集して推論して対応していくことも当たり前のように重要である。しかし、運用をしていたらそれでは解決しない問題にぶつかることもある。そのため、以下のような習慣を是非、身につけてほしいと思っています。各項目についてはこのブログでは深く記載しませんがぜひ、深堀りしてみてください。

1.コードがあったら読む

• コードが読めなければ障害やアラートの原因が最終的に神の怒りになる。
• OSSの動きが不思議だったら、外から動作を推測するよりコードを読んだ方が確実
• 案件でコードが公開されているなら、それもコードを読んだほうが確実
• 神様ではない限り読んだことの無いコードは分からない。
• 天才ではない限り読んだことの無いコードは書けない。

2.Strace でシステムコールを追う

• Linux にはあるプロセスが呼び出している system call を確認できるコマンドがある使えるといろいろと重宝するので使えるようになりましょう
• 例)パーミッションエラーが発生したがどこが悪いのかログに出てきてない！こんなときにはStraceだ！！！
• 最終的にはLinux プログラミングインターフェースと旅行に行きましょう！
• それでもダメなら起動せよ！デバッガー(gdbとdelve)！
• CPUやメモリのボトルネックを調査するためにプロファイリングツール(pprof など) を利用する

3. ネットワークトラブル時はTCPパケットを追う

• パケットは友達！パケットは嘘を付きません！
• RSTが返されているとか、応答自体がきていないなどの切り分けが必要
• ログやメトリクスだけではどうしても追いきれない場合がある

4.技術ドキュメントを書く

• 検討結果はもちろん、検討過程や思考を記録に残すことが大事
• 色々なやり方がある場合には「〜をする5つの方法」のような書き方
• 構造品質を保つ(構成が適切か、単語ミスはないか、口調はそろっているか、文法は正しいか、textlintをかけているか、構成テンプレートに沿っているか)
• 機能品質を保つ(サービスやビジネスの継続に価値を発揮できているか？)

5. OSSのバグがあったら報告する

• OSS のドキュメントでも良いのでフリーライドしすぎない
• 開発力が必要になるので身につく
• いつか、一緒に働いてくれるかもしれない誰かが見てるかもしれない

さいごに

というような社内ポエムを爆誕させていたらそこそこ反応が良かったので再編集してブログにしておきました。 もちろん、開発力も大事ですがそれらを通して原理原則を理解して自走しながら課題解決し続ける人の方がもっと価値のあることだとは思っております。 皆さんSREへの修行もしくは鍛錬がてら入社を待ってます！

3-shake.com

去年から同じようなこと言っていてますね、、。

syu-m-5151.hatenablog.com

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム