コミュニティの一生

  • このエントリーをはてなブックマークに追加

コミュニティの一生という言葉があります。

【コミュニティの一生】
面白い人が面白いことをする

面白いから凡人が集まってくる

住み着いた凡人が居場所を守るために主張し始める

面白い人が見切りをつけて居なくなる

残った凡人が面白くないことをする

面白くないので皆居なくなる

最近はこれを感じる事が多いです。

モチベーションの源泉

私が会社で働くモチベーションの源泉は何だろうと考える事があります。会社はレバレッジをかけて物事を進める場所であり、個人で出来ない事を実現する場所であり、そこでしか出来ない事を求めます。他でも出来るのであれば、別に今に拘る必要はないですね。

とある会社に入ったとき、周りに居た人は自分には持ち合わせていない能力を持っており、皆が自立的に動き、それぞれがプロフェッショナルな仕事をしていました。時が経ち、学生でも書かないような成果物を連日のようにレビューし、定期的にポーリングしなければならず、Giveされる事が当然だという意識が蔓延すると、心も体も消耗していきます。
テックカンパニーではない普通の会社になってしまったのだなと感じます。

一般的な知識の不足が多い状態では話が通じないばかりか、困難な事をクリアしてもそれがどれだけ凄いことなのかを理解して貰えず、幸せを感じる事はできなくなります。質の低い仕事の対応に追われ、シニア人材の戦力を割く毎日が続くと、優秀な人や自立的に動くエンジニアは次々と去って行き、益々魅力の無い環境になってしまいます。

Twitterを見ていると勘違いしそうになるけど、Productionコードが書ける人や一定以上のエンジニアリングが出来る人、上手に仕事を進められる人ってそんなに少ないのかしら。

消耗しすぎて外の人といっぱい話したい。

スクワットチャレンジ再開します

  • このエントリーをはてなブックマークに追加

スクワットチャレンジ再開します。

膝を痛めていたのですが治ったので運動再開。

このアプリを使います。

Runtastic スクワット回数カウント
https://itunes.apple.com/jp/app/id570183002?mt=8

とブログで宣言する事で自分を追い込む。

細かい事を気にする人だなと思った時に振り返る

  • このエントリーをはてなブックマークに追加

誰かに何かをお願いしたとき、「あいつは細かいところを気にするやつだな」と思うときがあると思います。

しかしそれはその人にとって普通のクォリティなのです。普段の仕事でそれくらいの事は凄い短い時間で考え抜いて答えを出していることが殆どです。

では何故細かい所を聞くかと言うと、それは前提となる情報が全然共有されていなかったり、足りていなかったりするからです。当人にとっては当たり前な材料が提供されないので、細かい所を聞かないといけない事になっているのです。それが無いと普段のクォリティにならないのです。

何かを天秤にかけるにも、情報が圧倒的に足りていないので判断ができないのです。

ふと冷静になって、なぜこんな事を聞くのだろうという考えを巡らせれば、相手の普段のクォリティに達する仕事の仕方をしていないと気が付く事もあります。

リハビリ終わりました

  • このエントリーをはてなブックマークに追加

前回、こちらの記事で膝を壊した事を書きましたが、その後のリハビリも終わりました。

いきなりランニングを再開するとまた壊しちゃうのが怖いので、ウォーキングとプールにしようかなと思います。

Jexerとかどうだろう。

Elasticache(Redis)の性能劣化 続報

  • このエントリーをはてなブックマークに追加

Meltdown, Spectreについて、前回の記事 にて、Elasticache(Redis)の性能が劣化した事を書きました。

そして先ほど、AWSのサイトにて次の記事が公開されました。

プロセッサの投機的実行に関する調査の公開について

その中に、

Intel のマイクロコードの修正により、一部のお客様のインスタンスとアプリケーションがクラッシュする問題を確認し、個別に対処させていただいております。当該事象への対処のため、それらの問題が見られる AWS の基盤に対し、マイクロコードの一部の修正を無効化いたしました。全てのインスタンスは引き続き既知の脅威からは保護されております。無効化された Intel のマイクロコードは CVE-2017-5715 による理論的な脅威に対して付加的な保護を提供するものでした。今後、Intel から修正されたマイクロコードが提供され次第、(現在取り組んでいるいくつかのパフォーマンス最適化とともに)これらの付加的な保護を再度適用いたします。

とあります。

Elasticache(Redis)の性能変化を見てみる

次の画像はCPU Usageのグラフです。

緑の線が最初のライブパッチ適用、青が前日、赤が当日。なので時系列的には、緑→青→赤となります。青の線が途中で急に下がっています。マイクロコードを適用したであろう時間帯と合っています。

他のRedisも似たように下がっています。

というわけで、もとの性能に戻りました😊

USB-C 充電アダプタを買いました

  • このエントリーをはてなブックマークに追加

これを友人からオススメされたので買いました。
ケーブルもAnkerのものを。他のケーブルは壊れやすいのですがAnkerのケーブルは全然壊れなくて良いですね。

Nintendo SwitchもUSB-Cなので色々と統一していきたい。寝室に1つ充電用のものを設置しました(`・ω・´)
ついでにモバイルバッテリーも、今使っているものが10年くらい前のものだったので新しく買いました。

dockerコンテナの中からホストとUDP通信する方法

  • このエントリーをはてなブックマークに追加

HostにDatadogが起動していて、Dockerコンテナの中からmetricsを飛ばすためにdogstatdと通信したい。でも、全然出来なくてなんでやねんと思ってたんですが、それは/udpを付けるの忘れていたというオチでした。

--net hostを付けて回避しちゃってましたが、-p 8125:8125/udpで良かった。

それでも、bashで/dev/udp/127.0.0.1/8125に書いても飛ばなかったような気もするけど..
うーん..

ポストモーテム アンチパターン

  • このエントリーをはてなブックマークに追加

先日、友人と飲んだときにポストモーテムの話になって、その時聞いた愚痴が、「あれ..この状況知っているぞ。どこも同じ感じなんだな」と思いを巡らせました。

その時に聞いた愚痴の要約は次の通りである。

  • 以前にも指摘している内容で障害を発生させている
  • 改善策が、基本的に精神論である(レビューを頑張る。もっときちんとチェックする等。)

この前読んだ記事でも似たような事が書かれていて、共感してしまいました。
「ちゃんと考えられない人」につけるクスリはあるのか。

ポストモーテムとは

ポストモーテムとは端的に言えば振り返りである。
レトロスペクティブという場合もあるようですが、ゲーム業界ではポストモーテムと言うことが多い気がしますし、SRE本でもIncidentの振り返りをポストモーテムと言ってます。

とあるオンラインゲームのProjectでは大規模パッチを1年に1回、大型パッチを3ヶ月、小規模な更新は1ヶ月や都度という頻度でリリースしており、大型パッチのリリースに合わせてポストモーテムを開催する事が多かったです。今の会社ではIncidentが発生した時のみポストモーテムをやっていますが、クォーター単位や大きな機能をリリースした単位で行うのが理想だと私は思います。

振り返りをしないとどうなるのか

Incidentの振り返りであれば同じ障害を何度も起こしますし、別の場所で同様のIncidentを発生させます。

Projectの振り返りであれば、スケジュールを毎回守らない人はずっと守らないままですし、何が原因でスケジュールが遅れるのか、見積もりが甘いのであればそれが精緻化される事は無くずっと同じ精度のままです。だらだらやる人はずっとだらだらやりますし、実力が足りない人はずっと実力が足りないまま進行します。
また、悪い点だけではなく良かった点も振り返らないので、そういった内容がチームで共有されずに、チームのボトムラインが上がりません。

アンチパターン

ポストモーテムではやってはいけない事が幾つかあります。ポストモーテムは、良かった点、良くなかった点を洗い出し、次同じ事が発生しないようにする、もしくは発生した時にきちんと対応できるように準備しておくための振り返りです。

今まで体験したもの、伝聞したもので良くないなと思ったものを列挙してみます。

  • そもそも振り返りをやらない(論外ですね)
  • 形だけの開催
  • 人の叱責
    • 何回も同じ事を繰り返していたら叱責する気持ちも分かるけど、それは別の場所でやってください。
  • 良くなかった点を一切議論せずに、次どうやって戦うかの話しかしていない
  • 表面的な要因を根本原因として分析してしまっている(クリティカルシンキングしましょう)
  • 改善策が根本対策ではなく、ただの精神論
  • 本質的に改善しないといけない項目を、しょうがないで片付ける
  • 1ヶ月後や長期連休の後に行う
    • とっくに忘れていて、どうでもよいマインドになっている
  • 解決策のTaskをいつまで経ってもやらない
    • そして次のポストモーテムで同じ事を列挙している

どうやって身につけるか

私はあまりビジネス書を読まないのですが、幸運にも若いときに在籍していたゲーム会社で周りの人に非常に恵まれていたため、よくあるビジネス書に書かれているような事を体現している人がそれなりに居ました。そのため、自然とそれを吸収する事で様々な考えが身に付いた気がします。

またProject兼任が多すぎて上司が片手では数えられないくらいだったので、多種多様な考えが身についたと思います。(そういう考え方の一部を社内Qiitaに公開していますが、あるタイミングでこのBlogにも転載します)

上記で挙げた記事にもありますが、何がきっかけになるかは人それぞれ。大きな障害を起こしても変わらない人は変わらないです。きっかけを与えてもそれがトリガーになるのかどうかは人それぞれなので、目くじら立てずに適度にスルーしていかないと、どんどん空しい気持ちに襲われるだけである。

最短距離で着地する戦術について

  • このエントリーをはてなブックマークに追加

何かの案件で最短で着地させたい、着地優先でという話が時々あります。その時の戦い方を間違えているのを頻繁に見るので記しておこうと思います。

良く遭遇する間違った戦い方

  1. 修正コードが少ないだろうからと、業務遂行能力の低い人に振る
  2. 既存の機能をこねくり回して無理矢理実現しようとする

それぞれ考察します。

1. 修正コードが少ないだろうからと、業務遂行能力の低い人に振る

Productionに40点の品質を出すわけにはいかないので、80点以上にする必要があります(状況によっては60点でも良しと判断する時もありますが、結局40点ではリリースできません)

こちらを参照

レビューには様々な目的がありますが、その1つには繰り返して良くないコードを書かないための教育も含まれます。ここを怠ってしまうと何度もProductionに出せないコードを書いてしまいます。またコードの品質だけでなく、コミットの粒度はこうした方がBetterではないかという話も含みます。

端的に言えば、いくら着地を優先するからと言っても40点の品質で出すわけにはいかないので、短い修正コードでも何度か往復する事になります。結果的にシニア人材の工数とジュニア人材の工数を使ってしまい、着地が伸びるという事に繋がります。
着地優先だからレビューを甘めにという考えがそもそもおかしいのです。

2. 既存の機能をこねくり回して無理矢理実現しようとする

ちょっと手を入れた方が確実に着地が早まるのに、既存の機能だけでどうにか実現しようとしてぐちゃぐちゃにする事案です。コードを書かない方が早いというのはQA工数など割けると考えているのか、単純に実力不足なのかは分からないですが、設定変更をしたり、普段とは違う使い方をするなら検証は必要です。それでも、どっちにしろQAやってないじゃんというお気持ちではありますが。
既存の機能の抜け道を考えてぐちゃぐちゃに考えた結果、それに時間がかかって最短で着地できないどころか、そもそも着地出来ないという事を見かけます。

コードに手を入れない事が最速であるという前提がそもそも間違っており、時間がよりかかる方法で積み木を変な風に重ねていって機能としてロールバックできない負債を作ろうとしているのに遭遇すると、一体何をしたいのだろうと思います。

まとめ

これを読むと、仕事を任せると言うことは〜みたいな話になりますが、そういう話ではなく本当に着地を優先させるのであれば、着地を優先させるための戦い方というのがあるという話です。着地が最優先と言いながら、理にかなった戦術をとらないのが目の前で何回も起きているので、首を傾げている毎日です。

あと、コンパイルが通ったからと言って正しく動くわけではないし、正常ケースのみ動かして検証したと言うのはQAでも何でも無いただの動作確認だし、ログや内部状態を見ないで動いたというのはエンジニアのやる行為では無い。という事も付け加えておきます。

Meltdown, SpectreにおけるElasticache(Redis)の性能劣化について

  • このエントリーをはてなブックマークに追加

仕事でAWSとGCPを使っていますが、1/4の19時(JST)過ぎにAWSのElasticache(Redis)の性能劣化が相次いで発生しました。後から調べてみるとRDS等も性能が悪くなっており、サポートに問い合わせたところこのパッチ適用が原因との事でした。

他の会社でもElasticacheが大変な事になっているようです。

Epicgamesにもこのような情報がありました。
https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update

なかなか辛いですね。

うちの場合

上に挙げたほど酷くはないですが、やっぱり影響は受けています。
次の画像は全てRedisのCPUグラフです。

ノードTypeが異なるのでCPU UsageのMaxが実質50%のところだったり12%の所だったりがあります。上2つはコア数が2なので50%, 最後の画像はコア数が8なので12%がMAX。

1月4日に急激にCPU使用率が上がっています。

赤色のラインが適用された週のMetricsで、青色が前週のMetricsです。アプリ側に対策を簡単な対策を入れて少し落ち着かせました。

ワークロード別ではZSet系scanが多いところが特に著しく性能劣化しました。とはいえ、hmset,hget,expire,delのような単純な使い方をしているところもかなり性能劣化していました。また、ある一定以上の負荷になると極端に性能が劣化する傾向にありました。

Aerospikeがどのように性能を受けるのか気になるところです。フォーラムには現時点(2018/01/07 23:36)ではまだ何も情報がありません。