MogLog

メモというか日記というか備忘録というか

『SRE サイトリライアビリティエンジニアリング』第6章読んだ

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

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

以下、『SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -』の第6章を読みながらメモをとったもの。第6章は「分散システムのモニタリング」というタイトル。


定義

  • モニタリング
    • システムに関するリアルタイム定量データの収集、処理、集計、表示を行うこと
    • 例:クエリの回数と種類、エラーの回数と種類、処理時間
  • ホワイトボックスモニタリング
    • システムの内部によって公開されているメトリクスに基づくモニタリングのこと
  • ブラックボックスモニタリング
    • ユーザが目にする外部の振る舞いをテストする
  • ダッシュボード
    • サービスの主要メトリクスのサマリビューを提供するアプリケーション
  • アラート
    • 人間に読まれることを意図した通知で、メールアドレスやページャなどのシステムにプッシュされる
  • 根本原因
    • ソフトウェアの欠陥やヒューマンエラーのうち、修正されれば同じことが同じように起こることがないと確信できるもの
  • ノードとマシン
  • プッシュ
    • サービス動作中のソフトウェアあるいはその設定に対する変更
    • memo: デプロイに近い??

モニタリングの必要性

  • なぜシステムをモニタリングするのか。その理由。
  • 長期的なトレンドの分析 のため
    • 日次のアクティブユーザがどういったペースで増加しているのか、など
  • 時間や、実験グループ間での比較 のため
    • ライブラリAとライブラリBではどちらの方が高速なのかを比較したり、サイトの速度が先週と比べてどうなっているかを比較したり
  • アラート のため
    • 何かが壊れていることや壊れそうなことを通知する
  • ダッシュボードの構築 のため
    • ダッシュボードは、サービスに関する基本的な疑問に答えるべきもの
  • アドホックな振り返り分析の進行(デバッギングなど) のため
    • レイテンシが急上昇したが、同タイミングで他に何らかの変化が生じていなかったか、など

症状と原因

  • モニタリングシステムは、2つの疑問に答えなければならない。それは、 “何が壊れたのか"と"なぜ壊れたのか” という疑問である。
    • “何が壊れたのか"という疑問は 症状 を示す
    • “なぜ壊れたのか"という疑問は 原因 を示す
  • “何が"と"なぜ"の区別は、シグナルを最大化し、ノイズを最小化する優れたモニタリングルールを書く上で最も重要な区別である

症状と原因の例

症状 原因
HTTP500もしくは400が返されている データベースサーバが接続を拒否している
レスポンスの速度が低下している CPUに過大な負荷がかかっている

4大シグナル

  • モニタリングにおける4大シグナルは、 レイテンシ、トラフィック、エラー、サチュレーション である。ユーザが直接利用するシステムで、メトリクスを4つだけ計測できるとするならば、この4つに集中する
  • レイテンシ
    • リクエストを処理してレスポンスを返すまでにかかる時間
  • トラフィック
    • システムに対するリクエストの量で、システム固有の高レベルのメトリックで計測される
    • Webサービスの場合、通常は毎秒のHTTPリクエスト数で計測されるが、リクエストの性格によって区分けされることになる
      • オーディオストリーミングのシステムであれば、ネットワークIOレートや同時セッション数に計測の焦点があたるが、キーバリューストレージシステムであれば、毎秒のトランザクションや取得数を計測することになるだろう
  • エラー
    • 処理に失敗したリクエストの割合
    • 失敗には明示的な場合、暗黙的な場合、ポリシーによる場合とがある
      • 明示的な場合:HTTPの500番台
      • 暗黙的な場合:HTTP200の成功レスポンスが返されているが、内容に間違いがある
      • ポリシーによる場合:例えば「レスポンスタイムを1秒以下にすると約束しているなら、1秒以上かかったリクエストはエラーである」というようなもの
  • サチュレーション
    • サービスがどれだけ「手一杯」になっているかを示す
    • そのシステムにおいて最も制約のあるリソース(メモリ、IOなど)に重点を置いて、システムの利用率を計測する

テイルレイテンシに関する懸念

  • 平均値のメトリクスの収集は危険になる場合がある。例えばCPU使用率やデータベースの平均使用率など、状況によって簡単にアンバランスになり得るものがあるため
  • 動作させているWebサービスの平均のレイテンシが毎秒1000リクエストの状況下で100msだったとして、リクエストの1%が5秒を占めることは容易に起こり得る
  • 低速な平均と、非常に低速なリクエストの「テイル」を最もシンプルに区別するには、レイテンシそのものよりも、レイテンシでパケット化したリクエストカウントを収集する。
    • 例:0 ~ 10ms、10 ~ 30ms、30ms ~ 100ms、100 ~ 300msといったような時間で処理したリクエストはそれぞれいくつだったかを見る

適切な計測の粒度の選択

  • システムの様々な側面は、粒度のレベルを変えて測定するべきである
  • 例えば、CPU使用率を毎秒収集すれば興味深いデータが得られるかもしれない。しかしこのような頻度での計測は収集、保存、分析のコストが非常に大きくなる。
  • サーバ内でサンプリングを行っておき、それらのサーバから順次データを収集して集計を行うように外部システムを設定すればそれらのコストを下げることができる(あくまで例)

可能な限りシンプルに、ただしやり過ぎないこと

  • これらの要求を全て積み上げると、モニタリングシステムは非常に複雑になってしまう
  • モニタリングシステムの設計をする際は、シンプルさに目を向けるようにする。以下は、モニタリングの対象を選択する上でのガイドライン
    • 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで、予想しやすく、信頼できるものであるべき
    • ほとんど実施されないデータの収集、集計、アラートの設定は削除すべき
    • 収集されてはいても、事前に作成されたダッシュボードのいずれにも表示せず、どのアラートにも使われていないシグナルは、削除の候補

原則の取りまとめ

※ ここは全くの写しになりそうなので書籍参照。

『SRE サイトリライアビリティエンジニアリング』第5章読んだ

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

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

以下、『SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -』の第5章を読みながらメモをとったもの。第5章は「トイルの撲滅」というタイトル。


トイルの定義

  • トイルとは何か

    • トイルとは、プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つもの
  • 以下の項目に1つ以上当てはまる仕事はトイルの度合いが高いと言える

    • 手作業であること
      • 例えば自動化スクリプトを手作業で実行する作業。スクリプト化して手作業を減らしてはいるが、スクリプトを実行するために人間が作業しなければならないのはトイルの時間と言える
    • 繰り返されること
      • 初めての作業や2回目程度の作業であれば、それはトイルではない。トイルは繰り返し何度も何度も行われるもの
    • 自動化できること
      • マシンが人間同様に行えるタスクや、そのタスクの必要性が無くなる仕組みが作れるのであれば、その仕事はトイルである
      • 逆に、人間の判断が欠かせないタスクはトイルではない
    • 戦術的であること
      • トイルは戦略的であったり予測に基づくものではない。割り込みで始まり、問題などが生じたことへの対応として行われる作業である
      • オンコールの対応はトイルである。この種の作業は完全に無くすことは難しいが、最小限になるように努めなければならない
      • memo: “戦術的” の対義語にあたるのが “戦略的” ?
    • 長期的な価値を持たないこと
      • あるタスクを終えた後でも、サービスが同じ状態のままなのであれば、そのタスクはおそらくトイルである
    • サービスの成長に対して O(n) であること
      • サービスのサイズ、トラフィック量、ユーザ数などに比例してスケールするようなタスクが含まれているなら、それはトイルである

トイルは少ないほうが良い理由

  • GoogleのSREチームは、トイルを各人の作業時間の50%以下に抑えるという目標を掲げている
    • SREの作業時間のうち、最低でも50%は将来のトイルを削減するか、サービスに機能を追加するエンジニアリングに費やされるべき
    • トイルを確認しないままにしておくと、急速に拡大して全員の時間を100%埋め尽くしてしまう傾向があるため、この目標を掲げている
  • トイルを減らし、サービスをスケールさせる作業が、サイトリライアビリティエンジニアリングにおける「エンジニアリング」である

エンジニアリングであるための条件

  • エンジニアリングの作業とは、新しいことをするためのものであり、本質的に人間の判断を必要とする
  • サービスに恒久的な改善を加え、戦略によって導かれる
  • 典型的なSREの活動はおおよそ以下のように分類できる
    • ソフトウェアエンジニアリング
    • システムエンジニアリング
      • プロダクションシステムの設定、設定の変更、システムに関するドキュメント作成が含まれ、1回の作業で改善効果が持続するような方法で行われる
      • 例:モニタリングのセットアップと更新、ロードバランシングの設定、サーバの設定、OSのパラメータチューニング
    • トイル
      • サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするもの
    • オーバヘッド
      • サービスを稼働させることに直結していない管理的な作業
      • 例:採用、人事の事務作業、ミーティング、バグのキューの整理、スニペット、ピアレビュー、自己評価

トイルは常に悪なのか

  • トイルは、必ずしも全員を不幸にしてしまうわけではない
    • 予測可能な繰り返しのタスクはごく穏やかなものである。こういったタスクは達成感と手っ取り早い勝利の感覚を生む
    • 低リスクでストレスが少ない活動であることが多い
    • 場合によっては、トイルを含むタスクに引き寄せられ、この種の作業を楽しめる人さえいる
  • トイルは常に同じように悪いわけではなく、多少のトイルは避けられないものだということは誰もがはっきりと認識しておかなければならない
  • 少量のトイルは気にしなくてよい。特にエンジニアがそういった少量の作業を楽しめるのであれば、トイルは問題ではない
  • 逆に言うと、 大量に処理しなければならなくなったときにトイルは有害になる
  • 多すぎるトイルが悪である代表的な理由
    • キャリアの停滞:キャリアアップが遅くなったり急停止する。つまらない仕事がキャリアを生み出すことはない
    • モラルの低下:多すぎるトイルは燃え尽きや倦怠、不満につながる

三浦半島 自転車旅行記

三浦半島を自転車で巡ってきたのでその記録を残す。

三浦半島とは

三浦半島(みうらはんとう)は、神奈川県南東部にある半島である。

※ from: Wikipedia

地図で言うと大体この辺り。 f:id:mogulla3:20170910215547p:plain

ルート(当初計画)

ルートは、大まかに次のように設定した。

地元の駅 → 横須賀駅 → 道中色々 → 城ヶ島公園 → 逗子駅 → 地元の駅

地元の駅 ~ 横須賀駅と、逗子駅 ~ 地元の駅は輪行をすることにして、その他を自転車でめぐる計画だ。 ちなみに輪行とは、電車などの公共交通機関を使って自転車を運ぶことである。

イメージはこんな感じ。大体70 ~ 80kmくらい。 f:id:mogulla3:20170910220425p:plain

地元駅 ~ 横須賀駅(7:30 ~ 10:00)

輪行は今回が初の試みなので余裕を持って早めに出発したが、自転車を解体するのに 2時間30分 もかかるという大惨事。出だしから大きく躓く。

自転車を解体して輪行袋に詰め込んだやつ f:id:mogulla3:20170910214513j:plain

初の輪行で気づいたことメモ

  • スタンドが邪魔
  • ハンドルが横に長過ぎて袋にうまく収まらない
  • エンド金具はリアだけでとりあえず良さそう

横須賀駅到着(11:30 ~ 13:00)

横須賀駅に到着したあと、今度はバラバラにした自転車を戻す作業を始める。 解体は大変だったけど復旧は余裕だろと思っていたが、結局元に戻すのに 1時間30分 もかかるという惨事。

なお1時間くらいはブレーキのパッドを取り付けるのに苦戦していた。涙。 f:id:mogulla3:20170910221719p:plain

ヴェルニー公園

自転車の解体と復旧に合計4時間も取られて落ち込んでいたが、気を取り直してスタート。やっと旅が始まる。 横須賀駅の目の前にヴェルニー公園という見晴らしの良い公園があるのでそこにフラッと立ち寄ったが時間が無かったのですぐに去る。

とにかくお腹が空いたのでおいしいご飯を求めて自転車を漕ぐ。

海軍カレー @ どぶ板通り

横須賀といえば海軍カレーハンバーガだろうということで、そのあたりを求めさまよう。 横須賀駅から約1~2kmくらいのところに、どぶ板通りという場所があったのでそこで食べることにした。

どぶ板通り f:id:mogulla3:20170910222440j:plain

海軍カレー f:id:mogulla3:20170909135411j:plain

うみかぜ公園

海軍カレーでお腹を満たしたあとは、うみかぜ公園を目指すことにする。 といっても、どぶ板通りから2km程度なのですぐにたどり着く。

うみかぜ公園 f:id:mogulla3:20170909131255j:plain

猿島がすぐ近くに見える f:id:mogulla3:20170909142703j:plain

観音崎浦賀の渡し

うみかぜ公園からは海沿いをひたすら走っていく。 観音崎海岸、観音崎海水浴場、観音崎公園などを横目に、写真を取りつつ進んでいった。

うみかぜ公園から浦賀まで約11~13km走り、そこで小休止をはさみつつ、渡船で反対側まで自転車ごと運んでもらう。

浦賀の渡し f:id:mogulla3:20170910223730j:plain

自転車を渡船に乗せ優雅にショートカット f:id:mogulla3:20170909154100j:plain

三浦海岸、そして時間と体力との戦い

渡船を降り、再び海沿いを走り続けると、三浦海岸にたどり着いた。気がつけば三浦市に上陸していた。 三浦海岸以降も海沿いを走っていたが、ここで時間があまり無いことに気付く。ゴールである馬の背洞門には日が沈むであろう18:00までにたどり着きたい。が、このまま海岸線沿いを走っていてはどうにも間に合いそうにもない。

国道134号線・県道26号線に乗れると大幅にショートカットできるのでそこを目指そうとしたが、随分前にその道に入るところを通り過ぎていた。残された道は、海岸線沿いを走るか、山越えを覚悟してショートカットをするかだったが、体力と時間の関係上後者を選ぶしかなかった。

三浦霊園のすぐ隣あたりまで来ていたので、この霊園をぶち抜いて県道26号線を目指す。 三浦霊園は案の定、心を折ってくる急勾配な坂がたくさんあり、ここで初めて自転車を手で押すハメになる。厳しい。

城ヶ島上陸、馬の背洞門へ

山道を乗り越え県道26号に入ることに成功し、城ヶ島大橋を渡って城ヶ島に到着する。このとき17:30頃。 既に体力というか太ももが限界を迎えつつあり、階段を降りると足から崩れそうになる状態。

城ヶ島公園に自転車を止め、徒歩で馬の背洞門を目指す。

城ヶ島には猫が沢山いた f:id:mogulla3:20170909175051j:plain

馬の背洞門に辿り着く

城ヶ島公園から約400m歩き、馬の背洞門にたどり着く。この時17:40くらい。

やったー。馬の背洞門や! f:id:mogulla3:20170909173741j:plain

日没の様子。馬の背洞門は暗いと見えないのでマジでギリギリだったと言える。 f:id:mogulla3:20170909173720j:plain

鮮味楽で三崎のマグロを堪能する

目的地にたどり着いた我らは、最後においしい三崎のマグロを食べてこの街を去ることにした。 軽く調べ、鮮味楽(せんみらく)というお店に入る。

鮮味楽。立派な看板。 f:id:mogulla3:20170910230028j:plain

2000円超えのまぐろ丼。写真を取るのを忘れていて、わさび醤油が既にかかっている。 f:id:mogulla3:20170909184203j:plain

帰路につく

夕飯を食べ終わったときには19:00を過ぎていた。 当初は逗子駅まで行く予定だったが、時間・体力的に明らかに無理ということが判明する。そのため、進路を逗子から京急線三崎口駅に進路を変更し、そこから電車で帰ることにした。

城ヶ島 ~ 三崎口まで約8.5kmだったが、体力の限界を迎えつつあった我らを絶望させるような坂道がたくさんあった。何よりも太ももの筋肉が悲鳴を上げている。エアーサロンパスの購入を3回くらい検討したレベル。本当にきつかった。

なんとか三崎口駅までたどり着いた我々は、再び自転車の解体をするが、勝手がわかっていたので30分程度で終わる。 2時間30分 → 30分という急成長を見せる。 なお復帰時間はさらに短く 15分程度で完了した。

最後に

自転車旅行は行き先だけではなくて、そこに至るまでのルートを細かく調べる必要があり考えることは多くなる。しかし当初の計画では思い浮かばなかったようなスポットや料理に出会えたり、状況に応じて自由にルートを変更できるのが良い。 また、電車や車の旅行よりも当然疲れるが、自分の力で進んだという達成感もあり、思い出に残る旅になること間違い無し。

色んなトラブルもあったが、そこも含めて楽しめた日帰り旅行だった。

『SRE サイトリライアビリティエンジニアリング』第3章読んだ

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

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

以下、『SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -』の第3章を読みながらメモをとったもの。第3章は「リスクの受容」というタイトル。


  • Googleは100%の信頼性を持つ、決して障害を起こすことがないサービスの構築に挑んでいると思われているが、実際はそうではない
    • 過度の信頼性はコストに跳ね返る
      • 安定性を最大化しようとすれば、新しい機能の開発やユーザへのプロダクトの提供速度が制限される
    • ユーザはサービスにおける高い信頼性と極端に高い信頼性との差異には気づかない
      • わかりやすく言うならば、99%の信頼性を持つスマートフォンを使っているユーザには、信頼性が99.9%の場合と99.999%の場合との違いはわからない
  • 以上のことから、SREは、単純に稼働時間を最大化するよりも、可用性におけるリスク・イノベーションの速度・サービス運用の効率性というゴールとのバランスを取ろうとする。

  • SREでは、サービスの信頼性を管理する大部分は、リスクを管理することによって行う

    • 信頼性を高めるためのエンジニアリングと、サービスの適切な障害許容レベルを定めることは等しく重要
    • サービスを十分信頼できるものにするために努力はするが、 必要以上に信頼性を高めようとはしない
    • 可用性のターゲットは下限でもあり上限でもある
  • 多くのサービスにおいて、リスクの許容度を最も単純明快に表す方法は、 計画外の停止時間の許容レベルという観点から見てみること

    • 計画外の停止時間はサービスの可用性に求められるレベルによって把握できる
      • ※ 可用性:システムが継続して稼働できる能力のこと
      • 可用性は通常、"99.9%“、"99.99%"などのように表され、稼働時間の比率を基に計算されてきた
      • 稼働時間を基にした可用性 → 「稼働時間 / (稼働時間 + 停止時間)」という式で表される
    • ★ しかし、Googleは稼働時間を基にしたメトリクスを使わず、 リクエスト成功率 という観点から可用性を定義している
      • リクエスト成功率を基にした可用性 → 「成功したリクエスト数 / 総リクエスト数」
      • エンドユーザの観点から見て、全リクエスト数に対する成功したリクエスト数として計算された可用性は、予定外の停止時間の近似値として妥当なものだとGoogleは判断したようだ
    • リクエスト/レスポンスという仕組みに直接関係無いシステムはどうするの?
      • 同じ原則の多くは適用できる
      • 例えば、あるデータを取り出して分析用に変換して別のデータストアに挿入するバッチスクリプトであれば、処理に成功したレコード数と失敗したレコード数という観点でリクエスト成功率を使う
  • エラーバジェットの活用

    • 異なるメトリクスの下で評価される開発チームとSREチーム
      • 開発チームのパフォーマンスは、主にプロダクト開発の速度で評価される。そのため、できる限り早く新しいコードを投入することにインセンティブが生じる
      • SREチームのパフォーマンスは、サービスの信頼性を基に評価される。そのため、変更の頻度を高めることとは反対の方向にインセンティブが生じる
    • こういった中で判断を客観的なデータに基いて下せるようするため、2つのチームは協力しあい、サービスレベルの目標(SLO)に基づく四半期のエラーバジェットを規定する。
    • 以下はGoogleのエラーバジェットの使い方
      • プロダクトマネージャーがSLOを定義する
      • 中立な第三者であるモニタリングシステムによって計測される
      • 上記2つの値の差異が、「損失可能な信頼性」という「予算」の残分となる
      • エラーバジェットがまだ残っている場合は、新しいリリースをプッシュできる
    • エラーバジェットのメリット
      • プロダクト開発者とSREに共通のインセンティブを提供することで、両者がイノベーションと信頼性の適切なバランスを見出すことに注力できるようになること
      • プロダクト開発チームが自己統制するようになる
        • 例えば、エラーバジェットが余っているときは速度優先の開発をしたり、逆にエラーバジェットがほとんど余っていない時は自身でテストをもっとするなどしてリスクを下げようとする
    • 計測されているSLOがネットワークやデータセンターの障害によって減ってしまった場合はどうするか?
      • こうしたイベントもエラーバジェットを消費する
      • SLOに対する責任は全員が共有するもの

『SRE サイトリライアビリティエンジニアリング』第1章読んだ

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

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

以下、『SRE サイトリライアビリティエンジニアリング - Googleの信頼性を支えるエンジニアリングチーム -』の第1章を読みながらメモをとったもの。


  • “シスアド"と呼ばれるシステム管理者のアプローチ

    • シスアドはプロダクトの開発者とは異なるスキルセットを求められる
    • そのため、開発者(dev)とシスアド(ops)は分離される
  • シスアドアプローチのメリット

    • 企業側にとって実施しやすい方法である
    • 業界で馴染みのあるパラダイムであるため、真似たり学びやすい
    • 人を集めやすい
  • シスアドアプローチのデメリット

    • シスアドのアプローチと、それに伴う開発・運用の分断には多くのデメリットと落とし穴が存在する
    • 直接的なコスト
      • サービスやシステムの成長と比例して、チームも大きくなっていかざるを得ない(※ memo:シスアドは手作業でやることが前提のようだ)
    • 間接的なコスト
      • devとopsのバックグラウンド、スキル、動機づけ、目標が全く異なることで軋轢が生じる
        • (例)devは新機能をリリースしたいが、opsは安定性を重視するのでリリースをしたくない
  • SRE

    • Googleはこれまで(シスアドアプローチ)とは異なるアプローチを選択した → これがSRE
    • ソフトウェアエンジニアを採用し、そのエンジニアにサービスを運用させ、従来であればシスアドが行っていた作業を遂行するシステムを構築する
    • SREとは、ソフトウェアエンジニアに運用チームの設計を依頼をしたときにできあがるもの (※ memo: これだけではよくわからない)
    • Googleにおいて、SREは2つのカテゴリに分類できる
      • 1.ソフトウェアエンジニア(50 ~ 60%)
      • 2.ソフトウェアエンジニアの必要条件をほぼ満たしながらも、ほとんどのソフトウェアエンジニアが保有していないがSREとして役立つスキルを持ったエンジニア(40 ~ 50%)
        • 特に、UNIXシステムの内部やネットワーキングレイヤ(レイヤ1 ~ 3)に関する専門知識をGoogleは求めているらしい
      • 全てのSREに共通するのは、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適性
    • SREは、これまで運用チームが行ってきたことをソフトウェアの専門性を持つエンジニアが行い、エンジニアが人手による管理を自動化するソフトウェアを設計・実装する能力を持ち、それをいとわないということから成り立つ
    • Googleは、全てのSREに対してチケット、オンコール、手作業といった「運用」業務の合計を50%以下にするよう上限を設けた
      • SREの目的上、SREチームはエンジニアリングに注力することが重要
      • この上限により、SREチームはサービスを安定して運用するための開発作業に十分な時間を確保できる
      • Googleが求めているのは、単に自動化されたものではなく、自動的に動作するもの
  • SREモデルの課題

    • 採用。SREの候補者がプロダクト開発の採用と競合するだけでなく、コーディングとシステムエンジニアリングの両面で採用の基準を非常に高く設定していることから、必然的に採用の対象者が少なくなる
  • DevOpsとSRE

    • “DevOps"の中核:
      • システムの設計と開発の各フェーズにおいてITに役割をもたせること
      • 人手ではなく自動化に頼ること
      • 運用タスクにエンジニアリングのプラクティスとツールを適用すること
    • これらは、SREの方針やプラクティスの多くとも一致する
    • DevOpsはSREの中核的な方針のいくつかを、幅広い組織、管理の構造、個人に対して一般化したものと捉えることもできる
    • 同様にSREをDevOpsに独特の拡張を加えたプラクティスと捉えることもできる
  • SREの信条

    • SREチームは以下の項目に責任を負う
      • サービスの可用性
      • レイテンシ
      • パフォーマンス
      • 効率性
      • 変更管理
      • モニタリング
      • 緊急対応
      • キャパシティプランニング
    • SREは運用作業にかける時間に対して50%という上限を設け、残りの時間はコーディングスキルを使うプロジェクトの作業にあてることが求められる
      • 50%を超過した運用業務はプロダクト開発チームへ差し戻す
      • 開発者をオンコールの担当者に組み込んだり、チケットをマネージャに割り当て直したりする
    • ページャが使われたかどうかに関わらず、全ての大きなインシデントについてはポストモーテムを書くべきである
      • ページを引き起こさなかったインシデントはモニタリングの欠陥を指すことが多い
      • 生じたことの詳細、イベントの根本原因、問題の解決策、次回はより良く対処するためのアクションの割当てを明確化させる
      • ページャー:ポケットに入る小型の無線受信端末。ポケベルのようなもの
      • ※ ポストモーテム:事後分析、反省会
  • エラーバジェット

    • エラーバジェットの導入により、devが求めるイノベーションの速度とopsが求めるプロダクトの安定性の問題を解決する
    • エラーバジェットは、"100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っている"という所見から生じたもの
    • システムの可用性のターゲットから1を引いたものがエラーバジェット
      • サービスの可用性が99.99%であれば、0.01%は利用できないことを示す。この0.01%がエラーバジェット
    • エラーバジェット(予算)は超過しない限り、必要に応じて何にでも使うことができる
  • モニタリング

    • モニタリングはサービスの所有者がシステムの健全性と可用性を追跡するための主要な手段の1つ
    • これまで一般的であったモニタリングのアプローチは、特定の値や条件を監視し、閾値を超えたり条件が満たされた場合に、メールのアラートを発するものだった
    • しかし、人間がアラートを読み、何らかの対応アクションの必要性を判断しなければならないようなシステムは、根本に欠点を抱えている
    • モニタリングにおいては、アラートの領域のどの部分をとっても人間の解釈が必要であってはならない。その代わり、ソフトウェアが解釈を行い、人間はアクションを行わなければならないときにのみ通知を受けるようになっているべきである
  • 緊急対応

    • 信頼性は、平均故障時間(MTTF)と平均修復時間(MTTR)との関数である
    • 緊急対応の効率性を評価する上で最も関係のあるメトリクスは、対応チームがシステムを健全な状態に戻すのに要した時間。つまりMTTR
    • 人間が関わるとレイテンシが生じるため、人間の介入を必要としないシステムは高い可用性を持つことができる
    • 人間が関わらなければならない場合、手順書を記録しておくことで、「即興でいく」よりもMTTRに3倍の改善が見られた
  • 変更管理

    • SREは、およそ70%のサービス障害は、動作中のシステムの変更によって生じていることを発見した
    • この領域におけるベストプラクティスは、自動化によって以下を実現すること
      • 漸進的なロールアウトの実装
      • 高速かつ正確な問題の検出
      • 問題が生じた際の安全なロールバック
    • 重要なのは、人手を除外するという点
  • 需要予測とキャパシティプランニング

    • 予想されている未来の需要に対して必要な可用性を提供できる十分なキャパシティと冗長性を保証する
    • キャパシティプランニングでは、自然な成長と突発的な成長の双方を考慮に入れる必要がある
    • キャパシティは可用性にとって極めて重要なので、SREチームがキャパシティプランニングを受け持つのは自然なこと

TOEICリスニングの問題が全然わからないので原因と対策を考えてみる

あらまし

最近TOEICのリスニング問題を解いているのだが、びっくりするくらい全然わからない。
これはアカンということで自分なりに原因と対策を考えてみたい。

解けないのはPart3とPart4

TOEICのリスニングは全部で4つのPartから構成されるようだ。

  • Part1: 写真描写問題
  • Part2: 応答問題
  • Part3: 会話問題
  • Part4: 説明文問題

このうち特にわからないのがPart3とPart4の2つ。 Part1とPart2も余裕で解けるというわけではないが、概ね自信のある解答ができているし、間違えていたとしても解答を見れば納得できることがほとんどだ。

問題の種類はそれぞれ異なるが、Part3とPart4は 問題となる英文が長い という点で共通している。逆に、Part1とPart2は短文の問題しか出ない。

英文が長(多)いと、解けない確率が上がっていくのではないか

解答の英文を見れば解ける

しかし、リスニング問題として解いたときには全然わからない場合でも、解答にある英文を見れば設問に簡単に答えられる。 つまり、リスニング問題として出されているものをリーディング問題のように読んで解くことができれば簡単に答えられるということである。

“そんなの当たり前だ"と言われそうだが、ここから分かることは英文自体は読んで理解することができているということである。 リスニング問題として耳から英文を受け取った際に、何らかの原因によって意味のある情報として受け取れなくなっているようだ。

原因の仮説

以上の現状分析から原因の仮説を考えてみる

仮説1:単語間の音が繋がることで認識できなくなっている

英語は発音されるタイミングで前後の単語がつながって発音されることが多いと思う。例えば「Should I ~」という英文なら「シュダイ〜」のように発音されるアレだ。 このように単語同士がつながって発音されることで、文として見た時は認識できていたものでも耳からでは正しく認識できなくなっている可能性がある。

仮説2:英文を読んで理解できる速度の限界を超えている

リスニング問題でも、実際の英文を読んで解くことができればほとんどの問題は解けると言ったが、自分の読んで理解できる速度はそこまで速いわけではない。リスニングの問題は英文を読む速度が速いと感じていて、ここが自分のキャパシティを超えている可能性がある。

もし読む速度が遅いリスニング問題なら解けるというのであれば、この仮説は確からしいかもしれない。 しかし、読む速度が遅くなったことで仮説1の音のつながりがなくなって理解できるようになったという可能性も考えられるので単純に考えることはできないかもしれない。

対策

仮説1の場合は、発音練習や音読練習をすることで一定の効果が得られそうな気がしている。発音練習で英語の音を理解し、音読で音のつながりのパターンを体に覚えさせる。

仮説2の場合は、速読の練習で一定の効果が得られそうな気がする。いつもより何倍か速く英文を読んでもちゃんと意味を理解できるように訓練する。もし読めなかった場合はどこで読めなくなったかを確認しつつ練習すればなお良さそう。

結論

色々考えてみたが、今はまだ質より量のフェーズだと思うのでもっとたくさんの問題を解いてみよう・ω・

「成るようになる」のではなく「人事を尽くして天命を待ち」たい

成るようになる

いろいろと気を揉んだり焦ったりしなくても物事はうまい具合に進行する、流れに任せてしまえばよい、といった意味合いで用いられる表現。「ケセラセラ」とも言う。

※ from: 成るようになるとは - 日本語表現辞典 Weblio辞書

人事を尽くして天命を待つ

人事を尽くして天命を待つとは、人間の能力でできる限りのことをしたら、あとは焦らずに、その結果は天の意思に任せるということ。

※ from: 人事を尽くして天命を待つ - 故事ことわざ辞典

つまり

「成るようになる」という言葉からはどこか思考停止・努力放棄といった印象を受けるのでどうにも好きになれない。 一方、「人事を尽くして天命を待つ」という言葉は、自分がやれることをやった後を自然の流れに任せると言う意味で、このメリハリというかバランス感が性に合っていて好きな言葉。

自分の好きなものを語るときに嫌いなものを一緒に並べるなとはよく言われるが、どちらかの言葉を聞くともう片方を想起することが多いので並べて書きたくなってしまった。

もちろん『黒子のバスケ』の中で一番好きなキャラは緑間真太郎です。
(「人事を尽くさん奴となど どちらにせよ仲良くなどできんな」のシーンを引用したかったがマンガの引用は若干グレーそうなのでやめた)