gometalinterの作者がリポジトリのarchiveを検討しているようです。
利用者にはgolangci-lintを使うように誘導し、
2019.05くらいまでにarchiveするようですね。
利用している方は切り替えるかREADMEをたまにチェックしたほうが良さそうです。
コミッターの方々お疲れ様でした。
書籍 SRE サイトリライアビリティエンジニアリングの紹介
この記事は、CyberAgent 19新卒 エンジニア Advent Calendar 2018の9日目の記事です。
はじめまして、サイバーエージェント19内定者の松田です。
この記事は、ここ数年でよく耳にするようになったSREという職種について、
名前と雰囲気は分かるけど今までのインフラチームとどう違うのかよく分からないという方向けの記事です。
SREを提唱したGoogleがSREの教科書ともいえる書籍Site Reliability Engineering(通称SRE本)の一部を紹介して、簡単にSREの役割を知っていただければと思います。
SREって絶対にサービスが落ちないようにするチームだよねという声が聞こえたので、
それは色々と誤解しているよということで、SREの成り立ちを重点的に説明します。
SREという職種については、参考文献のSite Reliability Engineeringとは。の記事が、より詳しく書いているので、ぜひご参照ください。
オライリーが出版している訳本が以下になります。全体の内容はぜひ書籍で！
はじめに、第Ⅰ部 第1章イントロダクションからSREの成り立ちについて触れます。
従来のシステム管理者(インフラチームなど)の役割
従来のシステム管理者の役割は、既存のソフトウェアを組み合わせてデプロイし、サービスを提供可能な状態にすることでした。 システム管理者はサービスを運用し、障害やアップデートなどのイベントが発生すると、その都度対処する必要があります。 システム管理者の役割で求められるスキルセットは、プロダクト開発者の役割で求められるスキルセットとは大きく異なるため、開発(Dev)チームと運用(Ops)チームという別々のチームに分けられることになります。
開発と運用でチームが分かれることの利点と欠点として以下のようなことが上げられています。
利点
- 人員の割り当てがやりやすい。
- 業界で馴染みのあるやり方のためドキュメントが多く学びやすい。また、関連する能力を持つ人を集めやすい。
欠点
欠点は直接的なコストと間接的なコストに分けて述べられています。
直接的なコスト
- 変更管理やイベント処理を手作業で行うチームがサービスを可動させる場合、サービスそのものの成長やトラフィックの増大に比例して必要な作業が増えるため、チームを大きくしていく必要がある。
間接的なコスト
- 開発チームと運用チームのバックグラウンド、スキルセットや動機付けなどが全く異なるために、大きなコストが発生する。
- 2つのチームは状況を説明する際に異なる用語を用いる。
- 技術的な解決策のリスクや可能性についても異なる推定をする。
- プロダクトの安定性の目標に対する想定も異なる。
- この考え方の違いは動機付けだけにとどまらず、コミュニケーション、目標、信頼と尊重にまで及ぶことがある。
- 旧来の運用チームと開発チームはプロダクト開発において衝突することがしばしばあった。
- 例えば、開発チームは新しい機能をリリースしてユーザが機能を使ってくれるところを見たいという欲求があるのに対して、運用チームは運用を担当している間はサービスに問題が起きないようにしたいという欲求がある。
- ほとんどのサービス障害は、新しい設定や新しい機能のローンチ、新しい種類のユーザトラフィックなどの何らかの変更によって引き起こされる。
- そのため、2つのチームの目標は基本的に対立関係にある。
Site Reliability Engineering とは
上記のように開発チームと運用チームでは暗黙的な対立が生じますが、この問題に対処するためにGoogleはシステムを動作させる体制を変更することを選びました。
これまでのアプローチから視点を変えて、SREチームでソフトウェアエンジニアを採用して、従来であればシステム管理者によって手作業で行われていた作業を実行するシステムを構築することにしました。
つまり、SREってなんなの？という疑問に対する回答は、以下の簡潔な1文で表されています。
SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに出来上がるもの
SREチームは常にエンジニアリングを行っていなければ、運用に伴う負荷が増大し続けていまい、負荷に対処するために更に多くの人員が必要となってしまいます。 これを避けるためにサービスの管理を受け持つチームは、運用業務にかかる手間を自動化するコードなどを書かなければなりません。 これを達成するために、GoogleはすべてのSREに対して、チケット対応、オンコール対応(緊急対応など)、手作業といった「運用」業務=トイルが業務全体の時間を占める割合を50%以下にするように上限を設けました。 この仕組みにより、サービスを安定して運用できるようにするための開発作業に充分な時間が確保できるようになったそうです。
50%ルールを達成するために
次に、SREチームにおける仕事の典型的な進め方の基礎となる原則の一部を紹介します。
トイルの撲滅
トイルというものは簡単に言うと運用作業を指しますが、Googleでは運用作業という言葉は誤解を招く恐れがあるため、トイルという言葉を使うそうです。
トイルの定義として以下の項目が示されています。
- 手作業であること
- 繰り返されること
- 自動化できること
- 戦術的であること
- 長期的な価値を持たないこと
- サービスの成長に対してO(n)であること
トイルは必ずしも悪いものとは限りませんが、放置しておくと少しずつ増え続け、大量になったときに非常に有害になります。 トイルがもたらす悪影響として以下の項目が示されています。
- キャリアの停滞
- モラルの低下
- 混乱の発生
- 進歩速度の低下
- 習慣づけ
- 摩擦の発生
- 信義違反
これらの悪影響を防ぐために、トイルに割く時間は50%以下と定めています。
SLO サービスレベル目標
SLAはよく聞きますし使うと思いますが、 GoogleではSLAだけでなく、サービスレベル指標SLIとサービスレベル目標SLOを明確に定義してサービスの評価を行っています。
SLIは、提供されているサービスレベルの性質などについて定義した計測量です。 SLIの例として以下の項目があげられています。
SLOは、SLIで定義されたサービスレベルの目標値や目標範囲を定義したものです。 例えば、平均レイテンシを100ミリ秒以下とすることなどの定義があります。
SLOを定めることで、ユーザから過剰に期待されてしまい障害時に影響範囲が想定以上に広がるなどの問題を避けることが出来ます。 また、可用性のSLOを充分に満たしているのであれば、多少の障害は許容範囲内なのでガンガン新機能を組み込むこともできます。 年度末に道路が綺麗になっていく現象に近いのかな(違う)。
まとめ
以上、ごくごく一部ですがSRE本の紹介を行いました。
これらの信条を達成するためにkubernetesなどのCloud Nativeなツールが利用されています。
インフラ系やSRE系ではない人でも得られるものは多いと思いますので、ぜひ読んでみてください！
参考文献
Site Reliability Engineering
「Site Reliability Engineering」を読んだ
SREって何？ これまでのシステム運用やDevOpsとは何が違うの？
Site Reliability Engineeringとは。
『SRE サイトリライアビリティエンジニアリング』を読んだ
SRE サイトリライアビリティエンジニアリング 1章まとめ
“SRE-サイトリライアビリティエンジニアリング- Googleの信頼性を支えるエンジニアリングチーム” を読んだ
HAProxy 1.6 のHTTP log formatについて
こんにちは、じょにーです。
今日はHAProxyのHTTPモードにおけるデフォルトのログフォーマットの中で重要そうなものについて簡単に解説します。
公式ドキュメントは以下のサイトです。
HAProxy version 1.6.14 - Configuration Manual