ファクトフルネスを読んだ感想

じゅーんさんが読んだと書いていて気になっていた、ファクトフルネスという本を読んだ。

june29.jp

思い出してみると本能に支配されていたなというエピソード

本書のなかに、「焦り本能」というものがある。焦り本能を抑えるには小さな一歩を重ねようとある。ここからは自分の過去の話だ。IT系のエンジニアとして、あるいは一人の人間として、上京したてのころは焦っていたように思う。「コードを書くことを毎日続けるのが良い」と言っている人を見て、自分がそんなにコードを書けないこともわかっていながら、ただただ焦っていたことを思い出した。でも、最近を振り返って見るとそこそこコードを書く仕事を続けているし、毎日とは言わずともだいたい毎日に近くコードを書くことと向き合えている。自分のモチベーションと向き合えるようになったからか焦りも消えた。

もう一つある。分断本能についてハッとしたことがあった。これはチームメンバーの発した言葉が、まさに分断を意識させる言動だったことがあって気が付かされた。あちら、こちらと分断して人や組織をカテゴライズすることは、分断本能によるものだとそのときに思った。もちろん、悪く言うつもりはないので、気が付かせてくれてありがとうと感じたエピソードだった。

感想

どのような人にもおすすめしたい。読んでみたらあなたの感想を聞いてみたいと思う。

割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話というタイトルでSRE Lounge #8に登壇します

こんにちは id:hokkai7go です。掲題の通りですが、3/13にクックパッド社にて行われるSRE Lounge #8に登壇します。

sre-lounge.connpass.com

id:Soudai さんへのリスペクトなのですが、登壇前に登壇予告の記事を書いておきます。以前書いた下記の記事は、2018年12月時点での割れ窓タイム運営について書いています。

blog.hokkai7go.jp

その後いくつかのアップデートがありました。今回のSRE Lounge #8 登壇に際して、割れ窓タイム自体のご紹介と最新のアップデートについてお話します。資料はこちらです。

speakerdeck.com

SREの扱う領域はとても広範なものであると認識しています。過去の経緯や特定分野に詳しい人からの知見を吸収したり、自分が教える側にまわるといった知見共有の課題を常日頃から感じており、このような取り組みと発表につながりました。当初の記事公開タイミングからいくつかの運営改善を行ったので資料に盛り込みました。同僚の皆さんと、発表の機会をいただいたSRE Lounge運営のみなさんに感謝しています。ありがとうございます。

誰かの心理的安全性が低いことがベースとなる心理的安全性について

ややこしいタイトルですみません。

最近少しずつ思うようになってきたことです。

心理的安全性というのは全員の安全性がベースにあるというよりは、実は誰かの心理的安全性を(実は)脅かす形で確保されているのではないかという仮説が僕の中であります。

 

個人的には、最近スクラムマスターとなり、このようなことを考えるようになりました。エンジニアリングマネージャー界隈が盛り上がっているのは、もしかしたらこのような背景があるのかな?よくわかっていません。

 

全員の欲求を最大限に満たすことはできないわけで、各自ストレスはあるし、ストレスの様子にはグラデーションかかった感じがあるなと思いました。もう少しまとまったらまたアウトプットしたいと思います。

Apache/Nginxによるリバースプロキシ(歴史的経緯が満載)をALBによって再実装した話

概要

これまでに終了したサービスなどの事情によりデータセンター上でApacheやNginxを使って、はてなで所有している様々なドメインに対するリバースプロキシを構成していました。簡単に言うとリダイレクトするだけなのですが、 48個程度のドメインとリダイレクト先の対応関係がありました。歴史的経緯というやつですね。これらのリバースプロキシの利用状況を調査し、統合方針の策定、ALBで再実装し、Route53でALBに切り替え、つい先日データセンター上のリバースプロキシたちを退役させることができました。今回はこの一連の対応での苦労ポイントについてご紹介します。

利用状況調査

2つのロール、合計5台のXen DomUでこれらのリバースプロキシは動作していました。幸運なことにWebサーバで読み込まれていた設定ファイルは1つのファイルにまとまっており、利用状況調査で難航することはありませんでした。またすべての設定がバージョン管理されていたことも良かったです。

調査項目は、

  • HTTPリクエストを受ける際のHost
  • リダイレクト先のURIパターン
  • ALBで実現可能か
  • リダイレクト内容(ホスト変更のみ/ホスト変更とプロトコル変更/ポート番号変更とホスト名変更)

としました。もし設定ファイルが複数のファイルにまたがっていたり、正規表現などを利用した複雑な条件でのrewrite設定などが入っていたら調査にかかる工数が膨れ上がっていたことや手戻りが発生していた可能性があります。ゾッとしますね。ここまで調査を終えた時点でチームに共有し、ALBで実現可能かどうかを最低限のテストパターンで実験することにしました。テストパターンの組み合わせは以下のようになりました。これ以外はもともとのリバースプロキシで実現されていなかったためテストパターンとしていません。

  • リスナー80、ホスト変更のみ
  • リスナー80、プロトコル変更のみ
  • リスナー80、ホスト変更とプロトコル変更
  • リスナー443、ホスト変更のみ
  • リスナー80/443以外のポート、ポート番号変更とホスト名変更

すべてのパターンをALBで実現可能ということと、リダイレクト先がIPアドレスの場合は対応できないことがわかりました。また後述しますが、この時点での実験内容はAWSのWeb画面であるマネジメントコンソール上で行っているという前提があります。はてなではCloudFormationによる構成管理が行われていることや、aws-cdk利用の機運の高まりもあるので今回のALBに関する設定全てをコードで管理したい欲求はチーム内で共有できていました。

統合方針の策定

  • 今回作成するALBは多くのFQDNを収容することが想定されるのでCloudFormationなどを使ってメンテナンスしやすい状態で構築するという
  • 2つのロールで実現されていたリバースプロキシたちを1つのALBにまとめる

などの方針策定をテックリードが行いました。終了サービスに関するリダイレクトをALBで実装しない判断もこのタイミングで行われました。

ALBで再実装

方針は決まったものの、実際実現できるのだろうかと不安になった点がありました。ALBのリダイレクト設定をCloudFormationなどで扱えるのかどうかがわからなかったからです。実際、再実装のタスクに取り掛かろうとしたタイミングではCloudFormationからはALBにおけるRedirect Actionの設定を行えない状況にあることがサポートへの問い合わせでわかりました。そのため一旦タスクを塩漬けにしました。

しかし、下記の記事の通りCloudFormationで実現できる見込みが立ちました。ありがたいアップデートでしたね。 https://dev.classmethod.jp/cloud/aws/aws-cloudformation-update-support-resource-and-using-elbv2-listener/

塩漬けにしていたタスクに再び着手しましたが、48個程度のドメインとリダイレクト先の対応関係をCloudFormationのYAMLファイルに落とし込む必要がありました(結果的にYAMLファイルは1000行を超えました)。これを手作業で行うことはできないと判断しました。なぜなら間違えが発生しそうであること、実装者である自分には集中を切らさずに手作業できる自信がないからなどの理由がありました。筆者はRubyが好きです。pryで処理を止めてデバッグできたり、漸進的にコードを書くことができる点が好きです。こうした利点を生かしてCloudFormationのYAMLファイルを部分的に自動作成するプログラムをRubyで書くことで手作業を避けました。

Route53でALBに切り替え

これらの再実装がうまくいったことをどのように確認したらいいのか悩ましいところでした。しかし、はてな社内においてはRSpecを利用したDNSのクエリテストの仕組みが存在しています。infratasterのinfrataster-plugin-dnsを使用したものです。今回の再実装においてもこの仕組みを利用しました。リポジトリのREADMEには以下のように書かれています。

クエリテストで infrataster を使用する利点は以下のとおりです。

  • 毎回、同じテストを実施することで、予期しない RR 削除/変更に気づける
  • dig などの手動テストではなく、機械的にテストすることで属人性を極力排することが可能

背景について補足説明をしておくと、はてなでは基本的にRoute53を利用してDNSのリソースレコード(RR)を管理しており、CloudFormation経由でこれらを管理しています。リバースプロキシに向いているトラフィックをRoute53でALBに切り替える作業も、CloudFormationのYAMLを書いて反映するのみで終えることができました。変更前後でクエリテストを行い、意図した結果になることを確認できたので安心して変更を行うことができました。

退役

切り替えが無事に済んだので、これまで仕事をしてくれていたリバースプロキシはめでたく退役することになりました。しかし、アクセスが来ていないことを確認してから退役したいという話になるのも当然の流れでした。アクセスログを確認、分析してみたものの判断に困ることとなりました。微妙にちょろちょろアクセスがあったのです…。この問題に関しては、アクセスログに記録されているIPアドレスとUser Agentごとに分類し、IPアドレスを逆引きしてどこからのアクセスがどのくらい多いのかを分析し、日本語で状況をまとめて判断をテックリードやプロダクトオーナー、チームメンバーに仰ぐことで捨てる勇気を持つに至ることができました。

まとめ

apache/nginxによるリバースプロキシ(歴史的経緯が満載)をALBによって再実装し退役に至るまでの技術的判断や技術的実装の概要を説明しました。レガシーシステムとの闘いは苦痛のように語られがちですが、計測・合意を行いながら進めることで現代的な形に生まれ変わることができると思います。むしろチャンスと捉えることもできそうです。今回はありがたいことに再実装に成功することができました。今後は可能な限り失敗についてのヒストリーも何かしらの形で共有したいなと思っています。

自分の状態をつかむ方法と良くないときの対処方法

アラートレベルで分類してみた。これを見た人の何かの参考になるといいな

critical

  • 好きな音楽を落ち着いて聞けず、曲をスキップしまくってしまう
  • 音楽を聞くと気持ちが落ち着くことすら忘れてしまって、音楽から遠ざかってしまう
  • 楽しい想像ができなくなっている
  • 拍動性頭痛や吐き気がする等明らかな体調不良

warning

  • 気圧変化に敏感になり、たまに頭痛がする
  • 歩くのが面倒になる
  • ワイガヤを騒音に思うようになる
  • 家でシャワーをしていて思い出し怒りをしてしまう
  • 肌の乾燥対策とかに気を向けられなくなる
  • 集中できる時間が短くなる

対処方法

  • 肉を食べる
  • 魚を食べる
  • 野菜を食べる
  • あたたかいものを飲む
    • コーヒーやカフェラテ、烏龍茶、スープ
  • しょっぱいものか、甘いものを少しだけ食べる
  • 好きな音楽を聞く
  • ドラムを叩く
  • そこそこにお酒を飲む
  • 散歩をする
  • 人と話す
  • マッサージや鍼に行く
  • 早寝
  • ジムに行く
  • サウナや銭湯や温泉に行く
  • 進行方向を向いて座れる電車に乗る
  • slackやDiscordのどうでもいいチャンネルを見てそっと閉じる
  • アイドルの動画を見る

あわせて読みたい

blog.hokkai7go.jp

YAPC::Tokyo 2019に参加してきた

はじめに

これです yapcjapan.org

はてながスポンサーになっていたのでスポンサーチケットで参加させてもらった。誰か行きませんかと社内で募集があったので手を挙げた感じ。同僚の id:papix が運営を頑張っているとJPA方面の方からも聞いていたので、行かない選択肢がなかった。社内に共有したメモから抜粋して感想等を書いておく。

Perlは勉強中で、最低限さくさく読めるようになろうとしているところ。

冬のPerl

Perl 5.28

Perl 5.30

  • 多少のパフォーマンス改善
  • Unicode11
  • なんかいっぱいエラーになるものがあるらしい

Perlを取り巻く状況

  • cpanのactive authorはだいぶ減っている
  • CPAN Pull Request Challengeが4年以上続いていた
  • Perl::LanguageServer
  • Perl 6.d がリリースされました

2019年の開発予定

  • MoarVMの最適化、部分的エスケープ解析
  • 高速化
  • 並行・並列処理

Rakudoとか、MoarVMとかわからん

広木大地さん講演

資料: 2つのDXと技術的負債-YAPC Tokyo 2019 - Speaker Deck

2つのDX - 開発者体験 - 企業のデジタル化

組織構造

  • 不確実性を減らすといい。減らすと生産的になれる
  • 組織も不確実性を減らしていく
  • 多くの不確実性に応えられるチームほど生産的
    • エンパワーメント型

コミュニケーション

  • エンジニアは否定ばっかりだから…というツイートがバズっていたが物事をはっきりさせたい様子が、否定形に見えてしまうのではないか
  • 情報の非対称性を減らすことがコミュニケーションなのではないか
  • コミュニケーションは、常識の距離が近いほど簡単。コンテクストが受け入れやすいから。常識の距離が遠くなるとコミュニケーションは難しくなる。このズレをすり合わせていけるのがコミュニケーション能力なのではないか

ダンバー数 https://ja.wikipedia.org/wiki/%E3%83%80%E3%83%B3%E3%83%90%E3%83%BC%E6%95%B0

  • 明晰な言語化という意味だと、立法行為と同じことをしているのでは
  • 我々エンジニアはコミュニケーションそのものをしている
  • 学習を促す心理状態になれば、本能を克服できる
  • 心理的安全性と責任の両方が高ければラーニングゾーンに行ける
  • 本能的機能は組織にも適応される: ゲシュタルト原則
  • 問題は、構造にこそあるのではないか。構造をリファクタリングする
  • ソフトウェアづくりはコミュニケーションそのもの
  • こういったことを考えていると、ポエムでしょ?と言われる

    • ソフトウェア開発を誤解した反応だと思うとのこと
  • ★ 要求インスペクション、よくわからんかった

    • 懇親会で聞いた: ペアプロ/モブプロも品質改善をするが、プロダクトオーナーと要求インスペクションをやることで、より上流工程での品質改善ができて効果も高いよってことだった。
  • コード解析より組織構造解析によるバグ予測のほうが成績がいいこともある
  • QCDのトリレンマを超える

よいチームの傾向

  • 関わる人数が最小限度
  • チームが本能的な恐怖を克服する方法を知っている ★これもよくわからなかったな
    • 懇親会で聞いた: →チームが組織学習できる心理的安全性があるとわかっている状態になっているかということ。なるほどね。
  • 多様性のある状態から認識を揃える力がある

組織構造とリファクタリング

  • 社内にも取引コストはある
  • 変えようとするとコストが非常にかかるものと簡単にできるものは、取引コストによって変わる
  • 組織設計とアーキテクチャの関係
    • 相互に影響を与え合う
  • システムは時間を経ると交換可能性を失ってコントロールを喪失する
  • ホールドアップ問題 - Wikipedia
  • なぜ多くのエンジニアは「技術的負債現象」と表現せざるを得なかったのかという論点
  • 見えてしまったら技術的負債ではないのかもしれない
  • 両利きの経営

結論と感想

  • エンジニア以外の職種においても情報の非対称性が解決され、エンジニアのDX(開発者体験)と、会社としてのDX(デジタルトランスフォーメーション)が同一になること
  • すごく納得した。どういうこと?と思われる方がいれば、エンジニアリング組織論への招待を読んでみることをおすすめする
  • 併せて読みたい: 「チームが機能するとはどういうことか」を読んだ感想 - 実はhokkai7go](https://blog.hokkai7go.jp/entry/2017/02/07/090655)

Dive into MySQL Error

資料

t.co

MySQLのエラー

  • エラーの分類
    • MySQLサーバのエラー
    • クライアントネガティブ応答
    • クライアントライブラリの異常
  • ネガティブな応答
  • 余談
  • MySQLエラーパケット
  • 先頭FF固定

エラーコード分類

  • 1000系がサーバ
  • 2000系がクライアントサイドエラー
  • 3000番台 5.7から
  • それ以上は8から

エラーコード分類による切り分け

  • 1000番台ならサーバ系
  • 2000番台ならクライアント
  • という切り分けはできる。まずはこれらと、3000番台なのかどうかを見る
  • syntaxのバリデーションはクライアントサイドではしない。

perror

  • perror というツールで調べられる
  • 2003番のエラーでも、どこでタイムアウトするかによってちょっと違う
  • MySQL has goneとか、サーバサイドの問題も一部2000番台に含まれている
  • 2059番 デフォルトの認証プラグインが変更された。古いクライアントから接続しようとすると、このエラーが出る
    • 5.7からは接続できるが、5.6以下はこれが出る
  • slaveはクライアント
    • エラーを起こすと、1000, 2000番台のエラーに従う
  • エラーメッセージ実は日本語にできる
    • 3000番台以降は日本語対応されていないからプルリクチャンスかもしれない
  • perror
    • 引数にエラーコードを受けて、内容を返す
  • 1593は、Fatal errorだけが決め打ちで、それ以降は状況次第で出し分けている。ググりにくい
  • エラー番号が分かれば、grepしやすい
  • プラガブルストレージエンジンのログ

まとめ

エラーメッセージを身近に感じてほしいとのこと。調べ方のためにもソースコードやドキュメントを読んでおくのは良さそうと思った。

Keynote

tokuhirom

  • PSGI/Plack
    • HTTP:Engineのリプレースプロジェクト
    • 他言語だと仕様と実装が分離されている。たとえばRack
    • 徹夜して書いたライブラリの話をフルセッションでやるのが許された牧歌的な時代
  • Amon2
  • Teng
    • O/R Mapper
    • 当時kamipoさんが言うところのクソクエリが話題になっていた
  • Furl

perldoc.jpの翻訳作業をやる人が一人しかいない。コントリビュートチャンス

さいごに

いい刺激をもらえた。onkさん、Songmuさんの発表の両方で感じたが、Rubyなど他言語のよいところを輸出入するという考え方はとてもよい。何の言語やツールかはわからんけど、なにかコードやドキュメントを書くことでの貢献をもう少しできそうかもという思いを持った。小さく始めて継続できる感じを探ってみたい。LOCAL学生部の人達に学生交通費支援制度あるってーと宣伝しておいたら本当に北海道から数人来てくれていて最高だった。学生同士でもワイワイしていたし、そこらへんにいたバリバリやっているエンジニアたちとも交流していたようだったのでとてもよかった。尊い

はい。それは私です。S.O.Sって曲最高だし、MAHO EMPiRE最高だよねと話した。尊い

LOCAL Community Summit 2019を主催しました

イベント概要

LOCAL Community Summit 2019(以後LCS2019と表記します)というイベントを1/19(土)に行いました。 これです。

local.connpass.com

過去に2回実施しており、2年ぶり3回目の開催となりました。

blog.hokkai7go.jp

blog.hokkai7go.jp

一般社団法人LOCAL(以下、LOCAL)という、「北海道の技術者コミュニティを盛り上げよう」という目的の団体の理事をやっていて、東京でもイベントやろうよ!って趣旨のものです。

イベントの説明はこんな感じです。

LOCAL Community Summit (LCS) は、

地方のエンジニアやコミュニティの取り組みを、地元だけではなく東京でも発表してみよう!
私達の地域の楽しさを、他の地域のエンジニアにも伝えよう!
地元を離れ首都圏で活躍しているエンジニアや、いろんな地域のコミュニティと繋がろう!
というテーマのもと、一般社団法人LOCALが北海道を飛び出し、東京で開催しているIT系勉強会イベントです。

今回は札幌地域へのU・Iターン促進イベント #みんなの札幌移住計画4 との同時開催で、「コミュニティ運営とエンジニアとしての成長」などをキーワードに、多彩なゲストをお招きして開催します。

札幌市への移住イベントとの同時開催という形でした。ちなみにLOCALは北海道の技術コミュニティに着目しており、札幌だけが北海道ではないと日々思いながら活動しています。もちろん、札幌は大好きです。

今回の特色

今回は、明確には募集ページには書いてないのですが、セッションごとにそれぞれセッションオーガナイザー的な人を置き、テーマぎめから登壇者確保までをやってもらう形にしました。後述する941さんの登壇内容から聞いたのですが、MANABIYAさんのカンファレンスでは、明確にセッションオーガナイザーが置かれていてオーガナイザーごとにその枠の取りまとめを行う形になっているそうです。それ、いいな。主催者の負担はできるだけ下げたい。

担当したセッション

僕は実行委員長役とSession1,2を担当していて、僕がどうしても直接聞きたかった人たちにお願いすることにしました。そーだいさんの「私とコミュニティと生きる道」という話と、941さんによる「エンジニアに愛される技術イベントを運営するために必要なもの、それは愛」という話です。どちらも自分の思っていたとおりにいい感じになって開催者冥利に尽きる感じでとてもありがたいですね。

そーだいさんセッション

soudai.hatenablog.com

ブログにも書いてもらっていました。激エモですね。私信ありがとうございます。真面目なことも書くと、LOCALという仕組みは先駆者が作ってくれた良い仕組みだと思っていて、他の地域でもあると良さそうと思っています。簡単に言うと北海道における技術コミュニティをつなぐというメタなコミュニティです。コミュニティ同士をつなげるというの、その地域を盛り上げるために意味があると思うんですよね。そのうえで、北海道と他地域をつなげようというのがLCSのやりたいことなのでした。京都に移住したこともあり、関西コミュニティとの出会いが少しずつあるので、また何かやりたいかもなと思い始めています。

それな。すごくわかります。

そう。コミュニティって、あなたなんですよね。この話を明確に説明しているとても良い記事があります。るびまという、Rubyist向けのマガジンには巻頭言があり、このようなことが書いてあります。とても好きな一文です。

コミュニティとは誰か。もちろん、あなたのことだ。あなたがコミュニティであり、 それ以外にコミュニティはいない。あなたのような人々の集まりを、コミュニティと呼ぶのだ。

コミュニティの新陳代謝についても触れられていて、思うところが多いセッションでした。

941さんセッション

941さんはこうおっしゃってるんですが、実際少し早めに終わったものの会場も盛り上がっていて質問がじゃんじゃん出てきていてとてもよい空間でした。何を思って、どういう苦労をして技術イベントをやっているかという話を、まさにイベントを主催している最中に聞けてとてもよかったです。

このtweetがいちばんきれいにまとまっていてありがたい感じです。絵文字って大事。

飲み会の幹事から始まり、1000人以上の規模にもつながるとはすごいですね。

はい!わかりました。

ほかセッション

ほかセッションについては、onodesとT_akmsが担当してくれました。 suzukiさん、jkudoさん、T_akmsの三人はよく知っていると思っていたけど、全然知らない興味深い話がでてきていて面白かった。特に、エンジニアのためのマネジメントキャリアパスを読んだ後だったからか、suzukiさんのキャリアパスに興味津々だった。

富良野から来ている、@tomio2480 (FuraIT)の話は年々凄みを増していて良すぎました。旭川富良野で学生さん向けのIT勉強会をやっている方です。

やっぱり後から見直しても何を言っているかわからないが、技術よりも場と人脈をつないでいくのが大事というのはとてもよくわかります。

話のつかみで豚汁の話が飛び出して、どんどんコミュニティの話になっていき、気がついたらめちゃくちゃ示唆のある話が押し寄せてきて、なるほどこれは現代落語のようなセッションだなと思いました。

学生に対しても、「僕は明日いなくなる。」と伝えてコミュニティ運営をしているのってすごいことだと思いませんか。常に属人性排除に向けて手を打つことを言っているわけでしょう。なかなか真似できない。この話を聞けて本当に良かった。

LT

OSC北海道参加者の方々は知っているかも知れない、sakuraさんがとてもありがたいLTをしてくれました。月並みかもしれないけど、自分の言葉で感謝を伝えられるのって大事なことだなと思いました。

LT枠埋まるかどうか心配だったのですが、結局5枠すべて埋まりありがたかったです。

合同企画

#みんなの札幌移住計画4合同企画「とことん、私とあなたの札幌移住計画」
#みんなの札幌移住計画4合同企画「仮想札幌市長選」

という2セッションを、合同でやっていただきました。実際に移住した人がLOCAL理事にもいて、彼らも登壇して移住についての質問に答えるというセッションがありました。実際の声が聞けるのはやはりとてもいいことですね。そのうえで、失敗についても語られていて良かったです。

さいごに

大規模イベントではないものの、やはりイベント運営はとても不安になることを思い出しながらやっていました。でも当日を迎えてみると、準備しっかりしたことや、人に任せることが少しずつうまくなってきたのか負担が下がったこともあり、やってよかったという気持ちがギュンギュンと出てきているところです。2018年末の引越から、ここまでの破滅したスケジュールをなんとか事故無く終えることができてとても安心した気持ちです。次回があれば参加したいとか、これまでやってきたことへの感謝をもらえるとか思っても見なかったので、続けてみるものだなーと思ったのでした。何より、参加者や関わった人たちが楽しそうにしている様子を見られたのがよかった。