ちくわ

ちくわにきゅうりを入れるとうまい

在宅環境 2020/04

日記

社のテックブログで自宅作業環境を取り上げてもらいました。もうこの時から3ヶ月が経とうとしてるんですね。

tech.pepabo.com

この時から引き続きスタンドデスクを利用しています。デスク周りは勤務時間からプライベートまで長時間接し、しかも自宅内で常に目に入る作業場所なので、以下のポイントで整えていきました。

  • 可能な限りケーブルは見たくない
  • 見えないところも雑にしない
  • 白ベース

デスク上・下・裏という流れで紹介していきます。

続きを読む

正しさについて考える機会

読書

この投稿は、GMO Pepabo Managers Advent Calendar 2019 7日目のエントリーです。 なんと前回の本ブログの投稿が去年のアドベントカレンダーなので、実に 1 年ぶりということになります。

最近読んで面白かった本を紹介

最近こちらの本を読みました。内容は、正義について高校を舞台に話し合うというものであり、少し前に話題になったトロッコ問題も出てきます。ここ最近読んだ本の中では（会話形式が続くため読みやすいというのもあって）二日程で一気に読み終えました。

続きを読む

趣味を通じた発見と気づき

その他

この投稿は Pepabo Managers Advent Calendar 2018の11日目の記事です。
前回の記事は@mayotoさんの「バリュー・カード」でした。

実にこのブログを更新するのは 1 年以上ぶりとなります。この 1 年間で難病にかかって文字通り無力になったり、現在の職場では部署のマネージャーというポジションに就かせて頂いたりと、公私ともに記憶に残る年となりました。

さて、上記にリンクしたブログ先をみて頂くとわかるように、クライミングを趣味としています。
この趣味は 10 年以上も続いているわけですが、スポーツや健康としての嗜みであればクライミングである必要はないのであり、今回はなぜそこまで長く続けていけているのか、自分の中で何に惹きつけられ魅力に感じているのかひたすら語ってみます。

f:id:ginbear:20181211192238j:plain

続きを読む

『第74回： SRE大全: 序章』hbstudy#74 に参加してきた

SRE

以下の勉強会に参加してきました。

hbstudy#74 - hbstudy

こちらがその本 ( 2017/8/19 発売

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

感想

SRE の概要や重要なポイントを解説して頂き、本を買わなくてもいいと思うものでは無く、本をより解釈できるためのガイドとなっていた印象をうけました。何しろいいボリュームですし、今回のような前説を受けてから読むことができるのはありがたいことです。
しかも、単純に紹介で終わっておらず、Googleの内情や、翻訳ならではの苦労話しも聞けて、非常に面白かったです (2h あっという間だった)。

印象に残ったのは、Google といえど、すごい人が魔法のようにシステムを構築/運用しているのではなく、地味な対応の積み重ねの話が出てくると聞いた時でした。Google 程のサービスでも、システムの運用は特別なものではなく、我々もやっていくしかないのだなと前向きなります。この本はそういったノウハウや考え方（原則）が詰まっているものと思いますので、参考にして自分たちのサービスに還元できる何かがあると期待したいです。

以下は今回の勉強会の書き起こしです。夢中でメモしていたら結構たまってしまった。
自身で解釈して表現をサマったところや、たまに、個人の感想（便利。とか）が入ってますので勉強会内容の正確な書き起こしではありませんのでご承知くださいませ :bow:

SRE hbstudy#74

諸説明

  • 司会が今回から持ち回りになった
  • 会場説明とか
  • インフラエンジニアが対象
  • 質問いつでも OK
  • ハッシュタグは #hbsuty

挨拶的な

  • 自己紹介
    • 翻訳出してる ( たくさんある
    • ヘルシープログラマ
      • おすすめ
    • 年内
      • SRE, LearningPySpark, Spark …

本日の内容

  • 面白いところをつまみ食いで紹介
  • 600ページ！！
  • SRE としてやっているわけではないよ ( 体験したことじゃないよ, 伝聞だよ
  • 翻訳した立場からの紹介だよ
  • 質問を期待しているので 2 時間分は確保してないよ
    • 質問はお気軽に。でも印税は答えられないよw

The SRE Book の出版

  • 原初について

    • The がついてるよ
    • PDFでダウンロードできる、フリーで
    • Google が share していく一環で公開
    • とにかく字が多い
    • 読み終わるとすぐだった印象 ( hadoop の本も同感だった

  • 日本でも

    • メルカリ、スマートニュース、サイボウズ
    • 大きな動きになっている

  • 翻訳した

    • マジで大変だった
    • 5000円越えして高い… けど、ワード単価だと 0.0025 で Docker 本(0.0034)より安い！
      • SRE 本お得だなぁ
    • 歴史的な名著になることは間違いない！( と思う
    • 構成大変
    • エラーバジェット (エラー予算と訳す？そのままバジェットにしよう)
      • シンボリックなキーワードはそのままがいいだろうということでカタカナを選択した

  • 自己主張したところ

    • サブタイトルを変更した
    • Google の信頼性を支えるエンジニアリングチーム

  • 技術論より組織論

    • 組織としてよく考えられている, 組織としての考え方が果たしている役割が大きい
    • Google だから、というわけではなく、学べるところは多い
      • チーム作りとか
      • フリーランスからスタートアップまで学べる面が多い

  • 目次

    • 34章ある
    • 半分ぐらいが組織論であることがわかる ( プレゼンテーション画面では組織論の章が赤く色分けされていた

  • 余談 ( SREのみなさんの仕事っぷり

    • 手が早い
    • Google Docs の使い方がうまい, 日常的に使っている感じ
      • 翻訳もスプレッドシートを使って、進捗管理された
    • スプレッドシートの機能を使って、自動化されている
      • 地道な自動化をきっちりやっている印象
      • 信頼性 100% は目指さない、コストがかかるから
        • 後世に関しては 100%を目指さざるをえない…

  • 余談 (三人称単数の They

    • 単数形で使われていることが増えている
    • He, She のように性別区分けすることを避けて(Gender neutral な表現として)、They と使っている
    • 最初誤植かと思った
    • 原書はその辺り気を使っている。 ~~のよ みたいな女性的な台詞回しも無くしている
    • Q) They はどうやって訳したの？
      • A) 一箇所しか出なかったのでなんかごまかした. それより会話の方が難しかった
      • 日本語だと男女がどうしても見えてしまうので、そこを気を使った、難しかった
      • He とか She の部分は名前になっている, 訳した時も全部名前にした
    • Q) カタカナ的なものをカタカナにするか英語にするかの判断基準 ( イシュー？ issue?
      • A) ケースバイケースで翻訳した、基本的には日本語にしたいよくはあった
      • Hadoop はアルファベットを多用した,
      • アルファベットの方が良いという反応があったが、ベンダ側から、読み方がわからないという話もあったので、カタカナよりにもしている ( 会話するときに困るという話が上がったらしい
      • 本の中で統一するということは気にした、本が分かれると変わるかも
      • ヘルシープログラマは日本語よりにして読み物として面白いようにした

SRE is

  • SRE という職種/チーム

    • 基本的には運用の人
    • Dev/Ops だと、 Ops 側の人
    • スキルとしてプラグラミングが必須である
      • Google の採用基準の 8 割ぐらいを満たしている人が必要
      • Dev としてバリバリできる人が SRE に採用される
    • 結構スター性がある人が採用される ( 運用だけをやってる人って訳ではない
    • Dev + インフラのスキルを持っている人、ハードル高い…
    • 仕事内容
      • オンコール対応 ( エスカレだね
        • 改善のための開発業務
      • サービスの開発チームは、サービスに属しているが、SRE チームは、全社横断的に存在している
        • サービスとインフラの間にいる図となる
      • 1 サービス 3 人ぐらいで作られている ( @google

  • SRE の原則

    • 信頼性、リアイラビリティに焦点が向けられている
      • 信頼性とは何か、の定義が厚く書かれている
    • ソフトウェアによって運用を自動化し、スケールする
      • SRE チームの規模はサービスの規模に比例してはならない！！ ( 原則
      • サービスの複雑さがました時は、SRE チームが増えるのはあり
    • トイル の撲滅
      • 自動化できるはずのこと、繰り返しやっていること、繰り返しても価値を産んでないもの
      • 人の時間を食ってるだけ
      • ソフトの力を使って解決し、時間を作り、本質の問題に時間を割くようにしよう
    • トラブル時、スキルのある人が徹夜をして解決しました！
      • ポジティブに語られがちだけど、否定的に取られている
      • 組織で解決していきましょう
      • トラブルの最中でも 17:30 にではと言って帰るというエピソードが出てくる
        • 火事場になって個人に負担がかかってしまうのを、組織で対処する
    • Q) Google の SRE の人数って？
      • A) 不明
      • 10月に Google で出版イベントやるかも？
      • Goole から偉い人くるかもよ
      • そのときに質問するといいかもw

休憩

速度と信頼性、そしてデータに基づく業務判断

  • 重要視 : 速度と信頼性

    • 新しい機能やサービスを投入するペースのこと ( 反応速度じゃないよ
    • 信頼性は SLO : Service Level Objective
    • 開発者(Devs)は速度を、運用者(Ops)は信頼性を重要視する傾向にある
      • ある種の対立関係, 緊張関係が生まれてしまう -> 解決しないとね
    • SREのキーワードとして、願望は戦略にあらずという話がある、うまくいってるのを祈るだけはやめよう
      • という話をしてプロジェクターが映らなくなったハプニングにつなげた

  • 計測されたデータに基づく業務判断

    • エラーバジェット & 50%ルール
    • 計測して、業務判断していきましょうというのがキモだろうと見ている
      • ただこの言葉をコピレばいいという訳ではなさそう

  • エラーバジェット

    • SLO(サービスレベル目標) : 計測するデータの定義
    • エラーバジェット = 1 - SLO
    • Google のサービスとして完全に使えなくなる時間は原則ない、ので、投げられたリクエストに対して失敗した数を計測する
    • サービスによって高める信頼性が変わってくる
      • 4 半期ごとに計測する
      • エラーバジェットが残っていれば、新機能をリリースできる
      • エラーバジェットが無くなった婆愛、リセットがかかるまで新機能のリリースは禁止
      • ルールとして決まっている、トップダウンで決めている

  • 100%は目指さない

    • 可用性は 100% は目指さない ( 普通は目指しがち
    • 100%は 意味がない
    • 99.99%の可用性と 99.999% の可用性の違いはユーザーにはわからない
    • それよりも、他の問題が要因になることが多い
    • 100%に近づける努力と見合わない
    • サービスの性格に応じた SLOの定義が非常に重要
    • 合理的に割り切りを行っている

  • 50%ルール

    • SREは作業時間の 50% 以上をエンジニアリング業務に割り当てなければならない
    • 運用業務に時間を取られ、50% を超えると、開発チームが SREの支援に時間を当てる
    • というのがルールになっている
    • データに基づいて業務判断を行うことをルール化することによって、Dev/Ops の対立関係を緩和している

  • Q) (質問聞きそびれた)

    • A) 基本 post で価を計測できるような仕組みなっている

  • Q) 計測手段がないものは？

    • A) 最初から仮想マシン上に計測可能な状態になっている.

  • 魔法の話はあまり出てきません

    • 全体的に技術者の地味な作業の話が出てくる
    • Google 独自の話って訳ではない、自分たちがどう学べるかという姿勢で読むと良さそう
    • Google はソフトウェアでコントロールできる範囲が広い
      • Vagrant や Terraform で似たようなことは、手元でできる
    • モニタリングできる仕組みも SRE が作った
      • いろんなチームに所属している SRE チームが自分たちのために作った、徐々に統一的に作っていった、成長させていった
      • 自分たちがツールを作って改善してくのとあまり変わらない、というところがわかって面白いよ

  • 徹底した自動化志向

    • 自動化のメリットは「複利」
      • 複利 -> 自動化によって空いた時間を使って自動化を進めるスパイラル
        • まめにやっていこう
      • 手動(トイル) -> 自動化 -> 自律化
        • 自動化で止めず、自律化までやっていかないとね、という話が出てくる

採用・育成

  • SRE の採用はたいへん

    • 要求スキルは高い
    • 需要に対して供給不足
      • SRE のエンゲージメント、サービスの立ち上げ時、SRE が関わる（コンサル的な）、サービス開発設計前から関わる、それでも人数が足りない、
      • SRE が開発したライブラリの出番！
        • これを使ってくれれば、SRE 不要
        • サービス判断に必要なメトリクスが取れる、ことになる。便利。
        • 既存のやり方に合わせるやり方はたいへん、レールから外れたやり方のものなど
          • これを指導するよりは、ライブラリを提供する
          • 自動的に広がっていく
    • SREは、単なるメンテナンスする人ではない、エキスパートという面がある。開発に向けてコンサルをする

  • 教育とオンコール

    • オンコール対応似なることはキャリアの一つのマイルストーン
      • skill も必要だし、サービスのことも知っている必要がある
    • 昔ながらの、感と経験と度胸、谷に突き落とすようなことは よくない としている
      • ドキュメント -> ポストモーテル? -> シャドウ -> オンコール
      • シャドウという一緒に横で対応してくれる教育者がいる
    • 推奨とアンチパターンの表がある
      • 試練を与えるようなやり方はよくない、とか
      • うまくいかなかった時は、個人を責めない、とか
      • 人工的に障害を発生させてシュミレーソションする、とか
    • シニア SRE もいる
    • 組織論としてよく考えられている、個人の熱意ではなく仕組みとしてやっていく

  • 障害対応とトレーニング

    • 年に一度全社的にトレーニングしている
    • 障害対応の手順はあるけど、やったことはない、とか久しぶりというケースはある
      • たまにしかやらないことは身につかない！と認める
      • 人間だもの
    • 障害対応手順を、日常業務に組み込んでおく
      • 普段からやっていることを、障害対応時にやるだけ

まとめ

  • 自動化二よってスケーラビリティの向上、トイルの撲滅、さならなる自動化のための時間を作る
  • ソフトウェアの力で運用改善
  • データの定義、開発とSREチームが同じ方向を向けるようにする

  • 組織論に注目して読んでいただけると

  • Q) SRO の定義がサービスと SRE でずれてしまった時はどうするか？

    • A) 重要なメトリクスはほとんど同じという記述があった
    • メトリクスが多すぎるのもよろしくない、なるべく共通した単純なメトリクスを推奨
    • Google は Web サーバの作りが標準なので、それで統一されているかもしれない、という印象はある

  • Q) ライブラリを提供する仕組み

    • A) Google の公式言語 4 つある, Go C+ python .. ..
    • SRE が提供する時は公式言語に基づいて提供する
    • Google サービスは階層構造になっている
      • インフラ的な階層もある、コンテナサービス

  • Q) SRE は一人当たりいくつサービスを見ているのか

    • A) 複数のサービスを受け持つこともあるし、一つのこともある
    • 人やサービスによりそう、ケースバイケース
    • オンコール対応をやっている人は 1 日に二つのコールを受けるぐらいがちょうどいい
      • 低すぎても、多すぎてもよくない、というところまでコントロールしている
      • 負荷の均等化をして質を保っている
      • データの計測と調整に紐付いている

  • Q) 作業時間はどうやって計測しているか

    • A) 計測方法は不明、でも計測して居るらしい
    • Q) なぜ 50%
    • A) 不明。50% を受け止めすぎる必要はないのでは

  • Q) xxx

    • A) 妥当な負荷で、オンコールを遣る話が
    • 一つの拠点や複数の拠点でオンコールを回す場合で異なる
    • Google の場合海外にも拠点がある場合があるので、日中帯であることもある

  • Q) SRE エンジニア、という言葉の冗長性についてどう思うか

    • A) SREngineer とか SREngineer Team と書いてある
    • 表現とズレが発生し始めている
    • SRE エンジニア は個人的には違和感ある

  • Q) 評価制度は出てくる？

    • A) この本は出てこない.
    • 与えたインパクトの大きさは、評価の一つらしい

  • Q) チーム担当の異動について

    • A) あるのでは？Google ないでもあるようです ( 推測

  • Q) コンテナ運用の話は乗ってる？

    • A) あんまり乗ってない
    • Google のインフラの話は 2 章で出てくるけど、詳しくは乗ってない
    • Borg の話はそんなに出てこないよ
    • モニタリングの話は結構出てくる

  • Q) 発売に向けて一言

    • A) みんな買ってね

最後に、hbstudy の設営のみなさま、ありがとうございました。 hb 飴美味しかったです。

安宅和人 (著) イシューからはじめよ―知的生産の「シンプルな本質」を読んだ

この本では、生産性を上げることを、同じ労力・時間でより多くのアウトプットを出すこと（= バリューのある仕事）としており、バリューのある仕事とは課題の質（これをイシュー度と呼んでいる）と解の質のマトリクスで表し、イシュー度と解の質がともに高い状態を指しています。

イシュー度 -> 自分の置かれた局面でこの問題に答えを出す必要性の高さ

解の質 -> そのイシューに対してどこまで明確に答えを出せているかの度合い

そして、ここで解の質を最初にあげようとするアプローチ（労働量、努力や根性で解を出すこと）を「犬の道」と筆者は読んでおり、先にイシュー度を上げるアプローチの重要性を説明しています。

理屈としてよく分かるし、（ケースとしては稚拙なものですが）何か問題解決するときに、問題内容を正確に理解せず思い込みでインプットしたのち、出した答えは何の価値もないものだったという経験は何度もあります。

働きをかけるベクトルは正しいものでなければ、その働きは何の意味もなく、当然生産性はステイどころかマイナス成長してしまいます。
(生産性 = 成果/投下した労力・時間 という方定期式で考えると、分母を無駄に増やしていることになる)

かといって問題を把握することに時間を費やしても、成果は出ないので、いかに効率的に・的確に問題を分析するかが重要になるかと思います。この本の序章以降はその辺りが書かれていました。

ただ、全体的に出てくるケーススタディが物流だったので、今の仕事に転換イメージするところで止まってしまい、序盤 〜 第１章（イシュードリブン - 「解く」前に「見極める」）あたりウンウンと頷いて読んでいましたが、後半は流す感じになってしまいました。

最後に、この本で刺激を受けた事として、以下を抜粋します。

どんなイシューもサブイシューも、答えを出して初めてそれに関する仕事が終わった、と言える。ここで大切なことは「停滞しない」ことだ。 要は手早くまとめていくのだが、そのためには次のコツを知っておきたい。

停滞を引き起こす要因として、最初に挙げられるのが「丁寧にやりすぎる」ことだ。- 中略 - 生産性の視点から見ると、丁寧さもすぎると害となる。- 中略 - 単に丁寧にやっていると、スピードだけでなく完成度まで落ちてしまうのだ。

『第４章アウトプットドリブン > 軽快に答えを出す > 回転数とスピードを重視する』より

ここでは丁寧すぎること指摘されていますが、継続的に・適切なボリュームのイシュー立てを行うことは大事だなと思うのでした。いつまでも閉じれないイシューや、定期的に見直しが必要なのにケアされていないイシューがあるケースを思い返しつつ…

伊賀 泰代 (著)「生産性」を読んだ

読書

読書会の課題図書ということもあって、ちゃんと？通して読みました。

生産性というテーマで、前半は生産性 is 何、本当にそれ生産性あることなん？という視点で語られていて、後半になるにつれ生産性をあげるための具体的なノウハウに移っていく流れです。

紋切り型な対応を挙げてより生産性の高い手段・考え方は何かを整理して説明されていて、話の流れも読みやすく腹に落ちる事が多い印象を持ちました。 （日本の対応あるある話がどこまで実際にあるあるなのかは分かりませんでしたが…）

個人的に刺さったのは、第３章にあった「成長とは、『生産性が上がる』こと」でして、以下一部抜粋です。

自分で目標を立て、その達成度合いに応じて評価される目標管理制度について「目標を低めにたてほうが得をするおかしな制度」と言った批判がつきまとうのも、その目標が量で決められているから

-> 成果も達成目標も生産性の伸びによって設定する -> 目標上限もなく、続ければ大きな進歩となる

量ではなく質を重視する組織になる。成果の絶対量の大きさではなく、生産性の伸びを評価する組織になる — これが今後の組織づくりにおける重要なポイント

-> 生産性を評価基準に取り入れると、労働の質に意識をむけるようになる

なるほどね〜