SREをどう始めるべきか？のヒントを貰った一日について
えらく遅い投稿となりましたが、2019/01/18(金)に開催された、SRE Loungeに参加してきました(｀･ω･´)ゞ sre-lounge.connpass.com
金曜日の19:00開始というスケジュールでしたが、ほとんど席が埋まってました。実際にSREを運用している企業の事例を聞いたり、懇親会で盛り上がっていろんな会社さんと話をしたりしていましたが、かなり面白い話が聴けて、3時間あっという間でした。
講演中の資料は以下です。公開していただき感謝。
※Speee天野さんの資料は見つけられなかった(´・ω・`)
詳細は資料を見ていただくとして、参加して私が感じたことや考えたことを書いていきたいと思います。
SREとはなにか？の理解
まずはSREとはなんぞや？的な話を私の理解でまとめてみます。SREと聞いてほとんどの方はこの本を思い浮かべると思います。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
Google社で昔から様々なサービスを提供し蓄積してきたベストプラクティスをまとめた本です。SRE本はGoogle社の事例であり、取り入れる企業の状況によって、SREでやるべきことは異なります。
しかし、SREを進めるときの考え方はおそらくどの企業でも共通だと思っていて、私個人的にはこのような認識を持っています。
「サービスを安定させて、顧客に最高のユーザー体験を提供し続ける」
これまでの開発・運用と大きな違いはなく、唯一違いがあるとすれば、「何をもってサービスを安定していると言えるのか？」を定量的に評価し、運用で得た知識を共有することを強制することにあると思うわけですね(｀･ω･´)
そのためにはまず、顧客に提供すべき基準であるSLA(サービスレベル契約)と、プロダクト側の目標値としてのSLO(サービス レベル目標)を定義します。合わせてSLOを評価するためのSLI(サービスレベル指標)を決めます。一般的には可用性やレイテンシがよく使われるかと思います。
目標値やそれを計測するための指標が決まると、エラーバジェット(許容できる停止時間)を算出できるようになります。例えばSLOが可用性99%で評価される場合、1%は「機能リリースのために使っていい停止時間」として扱えます。システムの信頼性を100%にするのは難しい、ならば許容できる範囲を決めてそれを守ればいい。
....始めて触れる考え方で、いい意味でショック受けました。使っていい停止時間が見えることで、気持ち的に余裕が出てくるのはいいですね。失敗しても基準値中に収まる、これが認識できるようになると必要以上にリリースを怖がることがなくなり、新機能や後述するToilの削減をガンガン反映していくことができます。
とはいえ、実際に障害を0にすることはできず、起きるときに発生してしまうのが奴らです。SREの文脈では、ポストモーテム(障害報告書)を”正しく”運用します。障害を失点と考えず次の学びとする。そのために発生した障害についてかなり詳細に記述する必要があるようです。
- 発生したこととその影響範囲
- その緩和や解消のために行われたアクション
- 根本原因
- 再発防止策
これらの情報を元に、発生した問題を集合知に変えたりシステム自体を改修するなどして、次回同じ問題が発生することを防ぐ活動をします。単にお偉様に報告するだけの資料ではなく、その後の改善を主目的に行う。当たり前に行っていきたい考え方ですね。
そしてSREといえばToilが多く語られます。定常的な運用作業、という体で扱われていることが多そうですが、ぱっとイメージするのは度重なる不具合調査とか、ぬくもりある手作業リリースといった運用のめんどくさい作業。こういった作業を自動化したり、そもそも運用を変えたりしてToilを削減していき、本来のプロダクト開発に使う時間を確保することが求められます。SRE本のGoogleの事例ではToilの作業を全体の50％以下に制限するルールだったそうです。後の50％は顧客価値向上のためのプロダクト開発に使う。
そもそもToilはいびつな運用を行っているために発生するもの、と私は思ってます。自動化してワンポチでリリースできれば一日に何回もリリースを行うことが可能だし、障害を発生させない仕組みに変更することでそもそも障害調査をする必要がなくなったり。 プロのエンジニアとして働いているのであれば、少ない労力で最大の効果を上げるよう振る舞うのは義務です。そのためにもToilを発見し、倒していく。継続し続ければ顧客価値向上の速度が更に上がり、ビジネスの結果にも繋がるでしょう。
感じたこと
SREを実践している3社の話を聞きましたが、やはり各社によって捉えかた違ってましたね。 メルカリさんでは事業の成長に沿ってSREを進化させ続けることに関心が多くあったり、一方グノシーさんでは、SREとは何で何をもって評価するのか？に関心が寄っているように感じました。SpeeeさんではSREを実践する組織づくりやメンバーの評価を見ているようで。
各社とも要求される品質も、必要とされるスピードも異なっているので当然のことなのですが、SRE本に忠実に運用するより何が自社にマッチしたSREなのか？を意識した上で運用を検討するほうが、よりワークするかと感じています。
弊社でもSREを導入したい、といった声は度々上がっており「弊社のSRE」を実践した後に、成果をこの場で発表できるようになるとGoodですよね(｀･ω･´)がんばります。
とても興味ある話多かったです。弊社でもこれからやっていく感出てきたので事例つくって発表するなり、なんらかの形で貢献 できるようにしたい(｀･ω･´)#srelounge
— しのゆ (@shinoyu) 2019年1月18日
心の声
SRE、いろいろ流派あって、会社ごとに運用全然違うんですよね...各社どういった定義しているのか知りたい #srelounge
— しのゆ (@shinoyu) 2019年1月18日
メンバーの得意領域で補って面で拾えること大事そう #srelounge
— しのゆ (@shinoyu) 2019年1月18日
割り込み多すぎてToil Limit is なに？状態で辛い #srelounge
— しのゆ (@shinoyu) 2019年1月18日
スクラムとかチケット駆動で開発してるならToil計測簡単に始められそう。ベロシティ計測、チケットをラベル化して集計。など #srelounge
— しのゆ (@shinoyu) 2019年1月18日
ビジネス側向けに手順まとめて、これ通りやれば大丈夫、みたいなコミュニティケーションはよくやってる(｀･ω･´)テックだけじゃなくてビジネスも巻き込んでToil撲滅できるの最高では？ #srelounge
— しのゆ (@shinoyu) 2019年1月18日
問い合わせフロー整備かなり効く。Toil削減に直結する #srelounge
— しのゆ (@shinoyu) 2019年1月18日
弊社まだSREをちゃんと運用し始めれていないこともあって、SREやってて楽しいことを聞いてみたい(´・ω・`) #srelounge
— しのゆ (@shinoyu) 2019年1月18日
懇親会の話題
懇親会は他の会社の方と結構話しました。
SREを運用している会社の方は全体の3-5割ほどでしょうか。これから導入し始めたい、といった弊社と近しい状況の方も多く話が盛り上がったのですが、経験者が少なくやり始めるのが大変という状況が伺えました。登壇して発表された方でもSRE経験者の採用に苦労している旨の話があるらしく、少ない人数でなんとかうまく回している、状況が実情なんだろうなーと感じました(´・ω・`)
新人を育成する、といった意見もありましたが、SREの領域だとエンジニア経験がかなり問われる気がします。障害のニオイや、対応の勘所といったスキルはある程度修羅場をくぐってこないと身に付き難いものですし。経験者を付けてOJTするにしても長期を見据えないと大変そうだなーという印象です。
後、記憶に残っているのは、SREエンジニアの評価をどうするか問題がありました。 もともとインフラ寄りの仕事である以上、どうしても正常に運用が回っている状況では必要性が感じられ難くく、評価し辛い話が生まれそうです。解決する手段として、SLOやSLIといったように今の品質がどうかを計測し、評価者に定量的な数値を元に評価してもらうことが可能になります。
「俺がいるからこの目標が達成できている」を自信持って言えるようにしっかり測定して追っていく。正しく結果と評価を結びつけることも大切ですね。
他にもいろいろと考えたことや書きたいことがありますが、今日は一旦このへんで(｀･ω･´)
キーボードは自作できる時代になってた
昨日行ってきました(｀･ω･´) 偶然、前の職場で昔一緒に仕事していた方と遭遇したのがこの日最大のハイライトでしたｗｗ
自作キーボードに関しては、以前からこんな記事をみることがあり、すごく興味あったんですよね(｀･ω･´) makezine.jp
そのうち体験してみたいなぁと自作キットの購入ページ眺めて感じていたんですが、ラズパイも放置している現状、作れる気がしなかったので手を出してませんでした。が、お試しキットが廉価で販売してまして、まずはそれから体験してみるのもありかな？と。
お試しキットと言いながら、基板にはんだ付けするタイプのもので本格度が見え隠れします。
はんだ付けするのかれこれ15年ほど前が最後だったので、はんだごて買って練習するところからですかね..._(:3」∠)_
写真は取れなかったんですけど、売り物としては、このお試しキット以外に個人制作の本や、キーキャップセットが販売されていたようです。ただ、helixといった自作キット系はおいてなく、売り切れ状態だったみたいです(´・ω・`)残念
意外とキートップのセットが高い。デザイン性のあるキーキャップのセットが販売されていたんですが、1万ちょい～2万5000くらいの価格帯でしたね。お値段高い分、一般的なキーボードより打ちやすそうな形状ではありますが。
自作キーボードの人口はまだ少ないので低価格化できるほど供給量が確保できてないんだろうなぁ、と感じました(´・ω・`) もちろん、必ずしもセットのキートップを買う必要はなく、その気になれば自作することもできるみたいですし、本気な方は自作を試してみると良いかと思います。 blog.livedoor.jp
他、店舗では自作コーナーもありました。この記事の冒頭で紹介しているITmediaさんの記事通りの設備とサービスですね。自分が行ったときも2、3名ほど作業をしているみたいでした。いざとなったら相談することもできそうですね。
まずはお試しキットを作ってみて、慣れていきたいと思います。
WSLのzsh、tmuxのコピペが動いてなかった(´・ω・`)
そういえば動いてないな～と放置していたんですが、最近本格的に触っている時間が増えてしまい、困っていたので対応しました。Macではreattach-to-user-namespaceを使いますがwslでは"win32yank.exe”ってのが該当します。Macで使っていたtmux.confの部分をこれに差し替えて再読込させてみたんです。
shinoyu/.tmux/tmux-Windows_Linux.conf:1: command not found: bind-key shinoyu/.tmux/tmux-Windows_Linux.conf:2: command not found: unbind shinoyu/.tmux/tmux-Windows_Linux.conf:3: command not found: bind-key shinoyu/.tmux/tmux-Windows_Linux.conf:4: command not found: bind-key shinoyu/.tmux/tmux-Windows_Linux.conf:5: command not found: unbind-key shinoyu/.tmux/tmux-Windows_Linux.conf:6: command not found: bind
なんでや( ﾟдﾟ)
Macだとbrew使うと普通に新し目(2.7とか)入るんですよ。もともとターミナル環境はMac先行で整備していたので、新し目バージョンの設定に沿ってconf書いてました。しかしwsl環境では読めず。
おもむろにtmux -VするとこのときのTmuxは2.1(´・ω・`)
# tmux -V tmux 2.1 # sudo apt install tmux パッケージリストを読み込んでいます... 完了 依存関係ツリーを作成しています 状態情報を読み取っています... 完了 tmux はすでに最新バージョン (2.1-3build1) です。 アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 0 個。
最新なんですよねぇ。どうもこのバージョンが引っ張っているパッケージは古いらしく。まあバージョン古いですからね、仕方ないですね。
# cat /etc/os-release NAME="Ubuntu" VERSION="16.04.5 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.5 LTS" VERSION_ID="16.04"
どうやらtmuxは2.4くらいから設定の記法に破壊的変更が加わっているらしく、2.7に合わせてた設定を2.1で読もうとすると、そんなコマンドねぇ！エラーが出てくるわけです。(´・ω・`) https://qiita.com/akinoriikeda/items/867b9d9a074538815886
おそらく、Macと同じく2.7以降に上げれば解決するはず。ただしUbuntuの向いてる先が古い、ということでtmuxを自前でビルドしてしまいます。
https://github.com/tmux/tmuxをcloneします。git tagを叩くと、2.8のタグが切られていたので、ブランチをこれに切り替えてビルド。
手順
- sh autogen.shを実行
autogen.sh: 15: autogen.sh: aclocal: not found
- ビルド失敗したので足りないライブラリ入れる
sudo apt-get install autoconf autogen
- sh autogen.shをして次は成功
- ./configureを叩いて、
configure: error: "libevent not found" sudo apt install libevent-devで依存パッケージ追加して再度./configure。正常に終わる- make実行。エラー
tty-term.c:24:21: fatal error: ncurses.h: No such file or directory - 調べてみると、これも必要らしい
sudo apt install libncurses5-dev - パッケージ入れてmake。通った。そのまま
sudo make install
一度tmuxのセッション落として、
# tmux -V tmux 2.8
ここまでやって、最新入りましたね(｀･ω･´) 一度すべてのtmux落として再度上げ直したら正常にtmuxでコピペができるようになりました。
2019/01/08 気になる記事まとめ
仕事も始まり、年末年始休暇からパキッとした仕事モードに戻す時期がやってまいりました。 残念ながら私はもどっておりません_(:3」∠)_
Githubさん太っ腹
この日一番のニュースだったんじゃないでしょうか。弊社でも話題になってました。 私はgithub課金者だったんですが、3人のコラボレータまで無料でprivate repository作れるなら、課金しなくてもよくなりました(｀･ω･´)
githubは今後より企業向けにシフトしていくんでしょうかね。直近だとActions
がパブリックベータやっていたりと、企業向けや有料ユーザーに対する機能追加で利益を得ていきそうな雰囲気ありますね。
scaffdogよさそう
ひと目見た時は、Markdownで記述していくの違和感あったんですが、宣言部とテンプレート部を1ファイルに収めようとすれば、こうせざるをえないんだろうなぁ、と感じました。 Rubyだとymlとerbを使ってgenerateするみたいなことをやってましたが、それに似ている印象。 新規でフロントやる機会があれば採用してみるのもおもしろそうですね(｀･ω･´)
gitの使い方がわかる良記事
普段なんとなく使っていますが、やはり使うのであれば理屈を知りたいところ。 細かな説明も妥協なくまとめられており、めちゃくちゃ理解しやすいです。初学者に理屈を覚えてもらうには大変よい記事ですね(｀･ω･´)
作業メモをどう管理するか
ソフトウェアエンジニアってかなり調べ物が多い職業だと思うんですよ。
APIドキュメント読んだり、実際に手を動かしたり等。調べたその時は頭の中に入っているんですが、1週間もすればすっかり揮発してしまうんですよねぇ...
この手の調査や作業メモ関連、皆様どのように管理しているでしょうか？
私個人としては、いろいろと試した結果、kibelaというサービスを使うことで決着してます。
kibelaについては、以前書いたこの記事で触れているので見てもらうとして、
以前は、テキストエディタでローカル管理、Simplenoteでオンライン管理と試してきました。ただ、それぞれに課題があり、なかなかうまく運用できてなかったんですよ(´・ω・`)
テキストエディタ運用時代
最初に考える方法の一つ。ただ、やはりというか当たり前な課題がありまして、
- オフライン管理なので、他の環境に行ったときに見れない
という点が辛く(´・ω・`)
会社で調べた続きを家で調べることも多くあり、いつでもアクセスできるところにあることが必要なんですよね。これではいつでもどこでも調べた結果を記録できない。git管理という手もあるんですが、外出中にiPhoneでgit管理、多分脱獄すればできなくはないんですが事前準備が面倒です。
結局これだけでは期待していることが満たせず、別の方法を模索し始めます。
Simplenote運用時代
次に手を出していたのが、Simplenoteですね。
読書メモやブログの下書きにも使っているんですが、よくあるオンラインメモサービスです。気軽に立ち上げて書け、検索もそこそこできるやつでした。Markdownも使えるので書き感も悪くない。
しばらくSimplenoteで運用して事足りていたんですが、使い込んでいくにつれちょっと使いにくいところが出てきました(´・ω・`)
作業メモとは、その時何を考えて調べたかをまとめたものです。つまり時系列の情報も必要になってくる。Simplenoteだと工夫をしないとその運用ができないんですよね。文書の中に日時を書き込むという人力運用でしたが。
ただねぇ、やはり都度都度日時を入力するのがめんどい_(:3」∠)_ 可能であればそこまで自動でやってほしいなぁ、と思ってました。
kibela運用時代
そして今に至るkibela。
このサービス、作ったページにに対してコメントを書けます。時系列の管理にこのコメントを使うわけですね。コメント入れて投稿すれば勝手に時間が記録される。Simplenoteでの課題が見事に解決されています。
調査している事項ごとにページを作り、調査した結果を都度コメントに記録していく。コメント部分でもMarkdownが使えるので調べたことをガシガシと書いていく。現状はこの運用が一番ラクにいけてますね(｀･ω･´)
こんな感じになります。
後から見直した後でも、何考えてたか追えることで思い出しやすくなる効果もあります。
今後生きていけるソフトウェアエンジニアについて考えた
あっという間に年明けし、親戚周りや宴会で疲労気味です、こんばんわ_(:3」∠)_ 関係者各位におかれましては、2019年も引き続き、宜しくおねがいします。
さて、タイトルが若干主語大きめなのですが、ここ数年エンジニアの需要に動きがあるのでは？と個人的に思っています。
従来どおり依頼された仕様書に沿って作っていくエンジニア、の募集よりビジネスとTechを回せるエンジニアの求人が(体感的に)増えてきていると感じました。去年の転職活動でもいろんな企業を見てきたんですが、SESを収益の柱としている企業以外では、ほぼ確実にビジネスにどういう貢献ができるか？といった軸での採用基準があるように思います。
ビジネスへどういう貢献ができるか？ソフトウェアエンジニアであれば、自身が持っている技術を駆使してビジネス価値を作っていけるか？に言い直されます。
ソフトウェアエンジニアの人材不足という声がよく聞きます。その一方で仕様を元に作るだけのエンジニアの数は十分だ、という声も聞きます。
転職市場においてビジネスを創発できるエンジニアの需要が大きいという感覚が正しいのであれば、つまりビジネスを成長できる人材であることが、今後生きていけるエンジニアとして必要とされている能力なのかもしれません。
と、親戚周りでお酒を頂いていたときにふと感じた、雑多な書き起こしでした。
2018/12/31 気になった記事まとめ
今年も後数分で終わります。年末最後のまとめです。 毎年このタイミングで体調不良なのなんででしょうね？ _(:3」∠)_
slackクローンのOSS
私個人の使い方だとまだフリーなSlackで問題ないので使う予定はないんですが、いざSlackで足りない場合に選択肢があるのはいいですな(｀･ω･´)
行きたかったけどタイミングが合わなかったJetBrain Night
こうして当時のセッション動画が公開されるのいいですね。タイムライン見ていた限りだと貴重が多くあったとのことなので、正月時間があいたら見ておきたいとおもいます。
本日は時間が取れなかったのでこんなところで。
来年も宜しくおねがいします。
