誰かに何かをお願いしたとき、「あいつは細かいところを気にするやつだな」と思うときがあると思います。
しかしそれはその人にとって普通のクォリティなのです。普段の仕事でそれくらいの事は凄い短い時間で考え抜いて答えを出していることが殆どです。
では何故細かい所を聞くかと言うと、それは前提となる情報が全然共有されていなかったり、足りていなかったりするからです。当人にとっては当たり前な材料が提供されないので、細かい所を聞かないといけない事になっているのです。それが無いと普段のクォリティにならないのです。
何かを天秤にかけるにも、情報が圧倒的に足りていないので判断ができないのです。
ふと冷静になって、なぜこんな事を聞くのだろうという考えを巡らせれば、相手の普段のクォリティに達する仕事の仕方をしていないと気が付く事もあります。
Meltdown, Spectreについて、前回の記事 にて、Elasticache(Redis)の性能が劣化した事を書きました。
そして先ほど、AWSのサイトにて次の記事が公開されました。
その中に、
Intel のマイクロコードの修正により、一部のお客様のインスタンスとアプリケーションがクラッシュする問題を確認し、個別に対処させていただいております。当該事象への対処のため、それらの問題が見られる AWS の基盤に対し、マイクロコードの一部の修正を無効化いたしました。全てのインスタンスは引き続き既知の脅威からは保護されております。無効化された Intel のマイクロコードは CVE-2017-5715 による理論的な脅威に対して付加的な保護を提供するものでした。今後、Intel から修正されたマイクロコードが提供され次第、（現在取り組んでいるいくつかのパフォーマンス最適化とともに）これらの付加的な保護を再度適用いたします。
とあります。
次の画像はCPU Usageのグラフです。
緑の線が最初のライブパッチ適用、青が前日、赤が当日。なので時系列的には、緑→青→赤となります。青の線が途中で急に下がっています。マイクロコードを適用したであろう時間帯と合っています。
他のRedisも似たように下がっています。
というわけで、もとの性能に戻りました😊
これを友人からオススメされたので買いました。
ケーブルもAnkerのものを。他のケーブルは壊れやすいのですがAnkerのケーブルは全然壊れなくて良いですね。
Nintendo SwitchもUSB-Cなので色々と統一していきたい。寝室に1つ充電用のものを設置しました(`・ω・´)
ついでにモバイルバッテリーも、今使っているものが10年くらい前のものだったので新しく買いました。
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の振り返りであれば、スケジュールを毎回守らない人はずっと守らないままですし、何が原因でスケジュールが遅れるのか、見積もりが甘いのであればそれが精緻化される事は無くずっと同じ精度のままです。だらだらやる人はずっとだらだらやりますし、実力が足りない人はずっと実力が足りないまま進行します。
また、悪い点だけではなく良かった点も振り返らないので、そういった内容がチームで共有されずに、チームのボトムラインが上がりません。
ポストモーテムではやってはいけない事が幾つかあります。ポストモーテムは、良かった点、良くなかった点を洗い出し、次同じ事が発生しないようにする、もしくは発生した時にきちんと対応できるように準備しておくための振り返りです。
今まで体験したもの、伝聞したもので良くないなと思ったものを列挙してみます。
私はあまりビジネス書を読まないのですが、幸運にも若いときに在籍していたゲーム会社で周りの人に非常に恵まれていたため、よくあるビジネス書に書かれているような事を体現している人がそれなりに居ました。そのため、自然とそれを吸収する事で様々な考えが身に付いた気がします。
またProject兼任が多すぎて上司が片手では数えられないくらいだったので、多種多様な考えが身についたと思います。(そういう考え方の一部を社内Qiitaに公開していますが、あるタイミングでこのBlogにも転載します)
上記で挙げた記事にもありますが、何がきっかけになるかは人それぞれ。大きな障害を起こしても変わらない人は変わらないです。きっかけを与えてもそれがトリガーになるのかどうかは人それぞれなので、目くじら立てずに適度にスルーしていかないと、どんどん空しい気持ちに襲われるだけである。
何かの案件で最短で着地させたい、着地優先でという話が時々あります。その時の戦い方を間違えているのを頻繁に見るので記しておこうと思います。
それぞれ考察します。
Productionに40点の品質を出すわけにはいかないので、80点以上にする必要があります(状況によっては60点でも良しと判断する時もありますが、結局40点ではリリースできません)
こちらを参照レビューには様々な目的がありますが、その1つには繰り返して良くないコードを書かないための教育も含まれます。ここを怠ってしまうと何度もProductionに出せないコードを書いてしまいます。またコードの品質だけでなく、コミットの粒度はこうした方がBetterではないかという話も含みます。
端的に言えば、いくら着地を優先するからと言っても40点の品質で出すわけにはいかないので、短い修正コードでも何度か往復する事になります。結果的にシニア人材の工数とジュニア人材の工数を使ってしまい、着地が伸びるという事に繋がります。
着地優先だからレビューを甘めにという考えがそもそもおかしいのです。
ちょっと手を入れた方が確実に着地が早まるのに、既存の機能だけでどうにか実現しようとしてぐちゃぐちゃにする事案です。コードを書かない方が早いというのはQA工数など割けると考えているのか、単純に実力不足なのかは分からないですが、設定変更をしたり、普段とは違う使い方をするなら検証は必要です。それでも、どっちにしろQAやってないじゃんというお気持ちではありますが。
既存の機能の抜け道を考えてぐちゃぐちゃに考えた結果、それに時間がかかって最短で着地できないどころか、そもそも着地出来ないという事を見かけます。
コードに手を入れない事が最速であるという前提がそもそも間違っており、時間がよりかかる方法で積み木を変な風に重ねていって機能としてロールバックできない負債を作ろうとしているのに遭遇すると、一体何をしたいのだろうと思います。
これを読むと、仕事を任せると言うことは〜みたいな話になりますが、そういう話ではなく本当に着地を優先させるのであれば、着地を優先させるための戦い方というのがあるという話です。着地が最優先と言いながら、理にかなった戦術をとらないのが目の前で何回も起きているので、首を傾げている毎日です。
あと、コンパイルが通ったからと言って正しく動くわけではないし、正常ケースのみ動かして検証したと言うのはQAでも何でも無いただの動作確認だし、ログや内部状態を見ないで動いたというのはエンジニアのやる行為では無い。という事も付け加えておきます。
仕事でAWSとGCPを使っていますが、1/4の19時(JST)過ぎにAWSのElasticache(Redis)の性能劣化が相次いで発生しました。後から調べてみるとRDS等も性能が悪くなっており、サポートに問い合わせたところこのパッチ適用が原因との事でした。
他の会社でもElasticacheが大変な事になっているようです。
This is what the #Meltdown patch looks like. pic.twitter.com/bR7chAH4uc
— Amanpreet Singh (@ApsOps) January 5, 2018
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)ではまだ何も情報がありません。
今年はあまりゲームが出来ない年でしたが、今年購入して、とても良かったゲームをまとめます。
Nierは今まで遊んだゲームの中で3本の指に入るくらいとても良かったです。前作を買ってからヨコオワールドに魅了されました。世界観と音楽がとても素晴らしいのですが、今作は開発がプラチナゲームズという事もあってアクションゲームとしても素晴らしい作品です。
とにかくプレイして欲しい。
ゼルダは言うまでも無いですね。
Switchは発売日に購入できましたが、実はNierが終わっていなかったので暫くやっていませんでした。あと最初にドラクエヒーローズを始めたのでゼルダは暫くお蔵入りになっていました。開発者インタビューが公開されて、CEDECで開発話を聞いて、やべえなと思いました。今まで個人の職人芸に強く頼っていた部分が、理論化されての大規模開発という事で、色々と衝撃を受けました。
DQ11は3DSでやりました。
2Dと3DがSyncして動いていて、なんて変態なんだと思ったけどテクニカルディレクターが紙山さんという事で納得。私はループ系のストーリーが好きなので、FFCCやNierは大好物なのですが、このDQ11もそうだったのでとても良かったです。ストーリーにウルウルきたのは久しぶりでした。ちょっと長かったので最後はダレてしまったけども。
FE無双。無双ゲームが好きというバイアスはありますが、FE無双はコラボ無双の中で抜群の出来でした。
まだ遊び尽くしていないので今年も暫くは遊ぶと思います。
ファイアーエムブレムな。商材名間違う人多すぎる。
アズールレーンはスマホゲームですが、艦これのシューティングゲームという感じです。
崩壊学園がよく出来ていると思っていたのですが、このゲームもそれの関係者のようですね。ゲームとして普通に面白いです。これも暫くは遊び続けると思います。ちょっと頑張ってランキングは19位まで入りました(o゜▽゜)
Steamのゲームもちょこちょこ遊んでいたり、3DSで不思議のダンジョンとかもやっていました。
2018年、期待しているゲームはオープンワールドの三国無双8、エースコンバット7です!!
ある組織において共通の目的を持っている場合、肩書きというのは何に重きを置いて問題解決していくかを示すものであり、ソフトウェアエンジニアはエンジニアリングに重きを置いて目的を達成するロールである。ただし、共通の目的を達成するというミッションが前提になっている事を忘れてはいけない。
時として「俺(私)は目的を達成するためにXXをやろうとしているのにそれを阻害する行動を取られる」と文句を垂れる人間が居ますが、それはその手段が相当な悪手か、そもそも共通の目的を共有出来ていないのが原因です。
さて、タイトルに書いた、速度を優先する事で品質が疎かになるのは正か否か。これは端的に言えば程度問題なので正でもあって否でもある。
ベンチャーにおいて、スケジュールが十分に妥当であること（まだ何も決まっていないが明日までに〇〇を出したいとかいうアホな事案で無ければ）を前提にすれば、ビジネスの速度にスケジュールが間に合わないのは技術力不足であると私は考えています。
スケジュールがタイトな場合に取る選択肢は幾つかあります。
最初に書いた前提より、1は無し。通常は2を選択する事が多いが、削ぎ落とすものが無い場合は3を選択する事になります。
ただし、こんな事をしなくても出来る人は出来てしまうものです。それはその人が超人だから出来ているのでは無く、日々の積み重ねがあるから実現できるのです。
日々の積み重ねとは、何かあった時に普段からモニタリングしていたり、ある程度予測して準備したり、仕組みを用意しておいたりする事です。何かの案件を小耳に挟んだときに、自分は関係無いと思わずに当事者意識を持って準備をする事です。
Productionに出しても良い品質を80点以上とします。
時として間に合わない時は管理職判断で60点でも良しとする事はあります、ビジネスを優先した結果そうする事もあるでしょう。ですが普段から60点や40点の仕事をする人間に対して40点でも良しとするのはナンセンスですし、絶対値基準として40点でリリースという事自体がナンセンスです。
良く着地優先なのでという理由でテストを一切書いていなかったり、そもそも筋が悪いプログラムのPullRequestがあります。普通にやっても人によっては余裕で着地出来る案件を、着地優先という理由で20点や40点で着地させようとするのは、ソフトウェアエンジニアとしての職務を全う出来ていない事になります。実力不足、技術力不足である事をスケジュールの問題に挿げ替えているだけです。
それを着地優先だったので良しとする文化は、ソフトウェアエンジニアとしての成長を妨げる事になり、能力の凹凸がより歪になり、延いてはエース/シニアエンジニアが尻拭いをする時間に追われ、組織としてスケールできなくなる構図が出来上がります。
これで辞めていった優秀な人材を何人も知っていますし、実際に見ています。
また、1カ所に権限を集中させるとミスジャッジが発生した時、議論の余地が無くなり、さらには議論をしても意味が無くなるので、そもそも議論をしなくなり、健全な体制にはなりません。能力と権限を対等に分散させれば上手くいくとは限りませんが、少なくとも同じ方向を向いている限りは上手くいかなかった例を知りませんし、集中させる事によって悪いことが起きた事例を何個も知っています。そして、また後者が発生したかと思う度に、権限が集中していると介入余地がないので改善する余地が無く、疲弊していくわけです。
60点で出す時はリスクが存在します。そのリスクをどのように扱うのかは大事な事です。
レースを例に挙げると、各種モニタリング、ガードレールやタイヤバリア、医療チームや救急車の手配の準備が万端であるからリスクを冒せるのです。
エンジニアリングも同様で、こういった何かあったら分かるようにする、何か起きたらそれに対処できるように準備しておく、といった保険があるからリスクを取れるのであって、保険をかけないやり方はただの無謀である。
こういった日々の積み重ねによって品質は成り立っており、何かあった時になんとか出来るように準備を積み重ねているのです。
金曜日にデプロイするのは禁止という原則が多くの会社にはあります。正確には、休みの前に初めて動くコードが無いことにするです。
これに対して文句を言う人が居ます。それだと着地出来ないとか、新機能をガンガン投入出来ないとか。プロジェクトのフェーズにもよりますが、あくまでも原則なので別に守らなくても良いのです。
ただし何故このルールが必要なのか、原理を理解しないで文句を言うのは筋が悪いです。
ルールが出来るのには何かしらの事象が蔓延っているからです。
金曜日のデプロイをする人間が、いつも40点や60点のプログラムを出しておりリリースの度にトラブルが発生させ、普段からアラートを見ている訳では無く、週末にアラートが上がっても他の人が対応しており月曜日になっても特に言及する事は無い。きちんとしたポストモーテム(振り返り)はせずに何回も同じ事を繰り返し、場合によっては不具合が発生している事に数週間気が付いていない。
このように何かあっても率先して自力で対処する事は出来ない（しない）人間に、金曜日デプロイを許可できますか? という話なのです。
何かあったら真っ先に対処しますという言葉も、普段の行動により信用力が伴っていないので、全く信用する事が出来ませんし、事実何かあってもその人間が対応しているのを見たことは殆どありません。真っ先に対応するという言葉だけでオンコールのローテーションに加わったりしているわけでもないのですから。
この原理を破っても良い人間も居ます。上記に挙げた行動とは逆で、スケジュールを殆ど守っており、品質も高くそもそもトラブルが殆ど発生していない。普段から真っ先にトラブルシュートをこなしている人間であれば、「何かあったら自分が対処するのでリスクを承知で反映します」という言葉にも信用が持てます。
このようにルールが出来るのには理由があり、文句を言う人間というのはそのルールが出来た原因である事が多いのです。しかしながら原理を理解していないため、自分で自分の首を絞めている事に自ら気づいておらず、どうでも良いルールが追加され、真面目にやっている人に迷惑をかけるのです。
最初から上手く出来る人はいません。何回か失敗を繰り返しながら成長していくものです。
何回も失敗している人は、振り返りが出来ていないのです。振り返りをやっても形だけでやっており根本原因を精神論で片付けている事が殆どです。
この様な状況に遭遇したとき、次からはどうするかを考え、対策を講じる事が大切です。何か失敗をしたのであれば精神論ではなく仕組みを持って解決していく必要があります。単純に実力が足りていないのであれば実力を付けるしかありません。
次どうするかを考える事を蔑ろにする組織/人間は、同じ過ちをひたすら繰り返し、信用を無くすだけではなく、周りの人間を疲弊させます。
最終的には、意識の高い人間やエース/シニア級の人材を何人も流出させる事に繋がっているのです。
集中した権力の暴走は、ある領域の今までの仕事/成果/信念を踏みにじる行為に捉えられ、完全にやる気を無くします。
