早めに帰ってきて晩ご飯を食べてからまたオフィスに戻って作業して2時に寝て7時半に起きた。

ストレッチ

今日の開脚幅は開始前153cmで、ストレッチ後155cmだった。先週よりは体力的に回復しているものの、今週も多忙で椅子に座っている時間が長かったので数値が悪くなっているのかもしれない。基本的には、お仕事が忙しい = 座っている時間が長い = 同じ姿勢の状態を維持する = 筋肉が固まったり運動不足に陥るという理屈で体調が悪化する。今週はなぜか右太ももの前あたりの張りが強かった。逆に腰や全身の負担は軽減したように感じた。開脚幅の数値はよくないものの、先週よりは復調しているような感触。実際のところはまだよくわからない。

ふりかえりとワークショップの定義からコミュニティ作りのなにか

書籍同様、タイムラインなどでみかけた記事を後で読もうと積ん読しておくときがある。次の記事もおそらく公開時期にみかけて気付いたら積ん読のまま1ヶ月が経過していたのを精読してみた。

• 価値発見に焦点化した振り返りワークショップの意義と、その教育学的分析

読み始めて、いくつかもの思いにふけりつつ、そこから派生して他の作業もしながら戻ってまた読み進めて、この記事を読むのに5時間かかった。そのぐらい私にとっては示唆のある読み応えのある記事だった。書いてあることのいくつかの点が他の事柄に繋がっていて、その点と線を確認しながら読み進めたので時間がかかってしまった。よくぞこの記事をブックマークしただけで流さなかったと過去の自分に感心したぐらいにはよい記事だった。ワークショップという言葉はよく聞く言葉ではないし、グループワークをする小さいセミナーのイメージを私はもっていた。教育学の分野の研究者によると次のような定義があるらしい。

ワークショップとは

• 講義など一方的な知識伝達のスタイルではなく、参加者が自ら参加・体験して共同で何かを学びあったり創り出したりする学びと創造のスタイル (中野民夫, 2001)
• コミュニティ形成 (仲間づくり) のための他者理解と合意形成のエクササイズ (練習) (仮宿俊文, 2017)

ちょうど課題管理の文脈でふりかえりをどう設計しようかを考えていたときにこの記事を読んだ。ふりかえりの目的を多義的に捉えるという発想そのものが私にはなかったのでそういった目的も含め、ふりかえりを実践していければよいのではないかと、自分の中にももともと燻っていた火種を見事に言語化してくれて示唆に富む記事だと感じた。

• 既存の業務に対する課題や改善の洗い出し (一般的なふりかえりの目的)
• チームのメンバーとコラボレーションする上で他者の考え方や意見を理解するきっかけの1つにする
• エージェンシーは自分一人では育まれず、同僚や上司、チームや組織との関係性の中で育まれる

ストレッチ

今日の開脚幅は開始前155cmで、ストレッチ後161cmだった。開始前の数値が悪いけど、とくに調子が悪いというわけでもなかったので計測の仕方がよくなかったか、たまたま足の開き方が悪かったかといったところだろう。昨日、高級時計と投資の話しを聞いたのでトレーナーさんとお金があったら何に使う話しが盛り上がった。トレーナーさんも庶民的な方でとくにお金があっても贅沢をしたいというものでもないらしい。私も改めてお金があったら何がしたいかを考えてみてもお金を使ってやりたいことはとくにないなというのが率直な思いでもある。私には自分がやったことのないことをやってみたいという思いしかなく、そのためにお金を使ってきた側面も多々あるけれど、お金を直接的に使って何かをやるというよりも、生活できるだけのお金があれば、その時間に自分がやったことのないことに挑戦して人生を楽しむということぐらいしかやることはないんだなと、トレーナーさんと話していて考えたりしていた。

os 雑談

午後から昨日の障害のふりかえりといくつか調査をして、夕方におがわさんに声をかけたら話し相手になってくれると返ってきた。障害のふりかえりをした後に課題管理の雑談もしていて4時間弱ぐらい話してた。私自身、反省しないといけないとは思っていたのでおがわさんはちゃんと指摘をしてくれた。この歳になると私を叱ってくれる人はいない。たまに失敗したときにおがわさんに話して然るべき指摘をしてもらえるのは本当にありがたい。

kubernetes がどうやって動いているのかを理解して運用しているのか？

コンピューターがどうやって動いているのかを理解しているのか？

私が未熟で理解できていなかったからこんな障害を見過ごしていた。システム障害が発生しても人生は終わりじゃない。反省してから次につなげる。おがわさんと話していて、os の仕組みや機能についていくつか教えてもらった。

• 制限対象の違い
  • ulimit はユーザーに対する制限
  • /proc ファイルシステムはシステムに対する制限
• /proc/sys/kernel/pid_max は kernel のデフォルト値として 32768 が設定されているが、systemd を使っていれば値を変更している場合がある
  • 私の ubuntu マシンだと 4194304 が設定されていた
• コンテナ内から /sys/fs/cgroup/memory/memory.usage_in_bytes をみると、コンテナが使っているメモリ量なのか？
  • cgroup の使い方次第で変わる、システムの値かもしれないしコンテナの値かもしれない
• ゾンビプロセスに残っている情報は親プロセスが子プロセスの統計情報を取得するために必要なもの
  • どんな子プロセスも一時的にはゾンビプロセスになる
  • kernel の task_struct 構造体やその他の構造体、リンクしている情報などをすべて足すと1つのゾンビプロセスが10数 KiB 程度ではないか
    • 仮に 15 KiB として 32000 個のゾンビプロセスがあると約 469 MiB のメモリ量になるのでだいたい数字があう
• ユーザー空間とカーネル空間の違いを理解できるようになった方がよい
  • システムコールの fork がエラーになるのはシステムがおかしいとすぐに気付けるはず
    • fork がエラーになる原因として考えられるのはメモリを確保できないか、pid_max に達したか、いずれにしてもエラーコードをみれば推測がつくのではないか
• 環境にログインできるのであれば strace を使えば障害調査に役立つ
  • 私が普段使っていないツールなので障害のときにとっさに扱えるよう練習しておく