「GitLab実践ガイド」を読んだ

はじめに

読んだ。

GitLab実践ガイド (impress top gear)

Git大好きエンジニアで、もちろんGitLabも仕事で愛用してますし、もう社内のGitLabなしでは僕は仕事できません(笑) 仕事のすべてをGitLabにおいてるので。。。まぁlocalでは作業できるけど。。。

そんなGitLab大好きマン、この書籍出るっていうのでまぁまず買うよね。

軽く内容をさらいつつ、気になる点はgitlab.comで試してみる。

第1章 GitLabが目指す開発スタイル

まずはプロダクトの思想から。大事ですよね。

DevOpsの考えを前提とした上で、ConvDev(Conversational Development)というスタイルを推奨しています。

ConvDevは、開発プロセスフロー全体において、グループメンバー同士のコミュニケーションを重視してアプリケーション開発を行う自然な開発スタイルです。具体的には、開発者は一貫性のある方法で、開発プロセスの一つひとつを追跡することが求められます。ConvDevでは、アイデアから展開までのコラボレーションと知識共有を促進することで、開発ライフサイクルを加速することを目指しています。

わかりづらいですが、DevOpsを支えるためには、コミュニケーションの促進だったり、課題の見える化が必要で、それを支える機能を取り込もうという思想ですね。

GitHubのGitHub is how people build softwareと同じですね。GitHubはソフトウェア開発そのものだ、というのと似ていて、GitLabはソフトウェア開発で必要になるコラボレーションまで含めて支援していくという思想です。

プロダクト/サービスをどう変えていくか、どう作るか、どいったアイデアを生み、それを開発に落とし込み、さらにそれを実際にプロダクト/サービスに反映する、このサイクルを促進する仕組みを持ち合わせています。

CI/CDをサポートしている、といえば味気ないですが、単なるテストやビルド、デプロイの自動化ではなく、継続的なプロダクト、ビジネスの改善という広い視野を持っている、といったところでしょうか。

第2章 GitLabの導入

内部コンポーネントの解説があるのはいいですね。いざ自分がオンプレで運用するようになったときのトラブルシューティングに役立ちそうです。今回は流し読みしました。

あとはインストール、セットアップ方法なので、ここも適宜必要なときに参照すればいいかなと思います。すでに導入済みなので流し読みしました。

にしてもGitLabのomnibusパッケージはinstallもupdateもすっごい楽ですね。すばらしい。最近8系から10系にupgradeしましたが、postgresのupgradeが必要だったぐらいで、あとはなんなくできました。

第3章 GitLabを使ってみよう

この章はGitLabの使い方で、自分は知ってるので流し読み。ユーザ/グループの概念の説明、登録方法。あとは基本的なGitの使い方。本当にはじめて導入するひとに対してやさしいですね。

Gitの概念、使い方は本当にわかりやすく、実際のコマンド含めコンパクトにまとまっているので初心者向けの説明に重宝しそうです。活用します。

第4章 開発ワークフロー

1章で述べたビジネス解決のためのアイデア共有のための仕組み紹介です。まずはslackクローンのchatシステムであるmattermost。社内ではオンプレにmattemrostとgitlabそれぞれ展開してますが、gitlabに付属してるmattermostは使ったことありませんでした。連携が若干楽になったりするのかな？とりあえず今の所は自分で立てているgitlabでmattermostは使わないと思います。

社内共有のgitlabでmattermostが使えるかどうかは確認したいところ。

あとはissueを使ってチケットトラッキング的なことができるので、redmineいらないんですよね。カンバンボードもついていて、commitやMRと紐づけられるのが本当に便利です。

リソースの参照で、#がissueなのは知ってたけど、!はMR、あとはマイルストーンやスニペットもあるんですね。知らなかった。

あとはブランチ戦略ですね。GitLab-flowが紹介されています。

第5章 継続的インテグレーション

この章はgitlab-ci.ymでコントロールできるCI設定と、そのためのgitlabci-runnerについての説明ですね。ここも既知だったので読み飛ばし。gitlabの最大の利点はここにあると個人的には思ってます。githubだとcircleciだtravisciだ外部サービスを使わなきゃいけないので。gitlab-ciは本当によくできている。

Executerはdocker一択かなぁと思います。

第6章 継続的デプロイ

ここで扱う内容は今までやったことなかったんですが、deploy先はどこになるかというと、コンテナでdeployした環境になるんですね。

この本で見る限りは、まぁintegration testはコンテナを使ってgitlabでテストすることはまぁわかるんですが、本番deployが例えばAWS上とか、別の区域のクラウド上とかそういう場合はどうするのかな？っていうのが疑問です。

runnerを本番とステージングでわけて、本番構築用の環境からrunnerが反応するようにしておけばどこのクラウドだろうができるって感じですかね。docker(コンテナ)っていう前提ですが。

本番がgitlabとIPでreachするかどうかが重要ですね。

例えば僕が持ってる静的webサイトの本番deployはcircle-ci上でS3とsyncさせてやってます。本番環境にrunnerを動かしておいて、コンテナdeployできる環境があればgitlab-ci.ymlの定義で簡単にできそうですが、クラウドが当たり前の現在で、例えばECSとかと連携が楽にできるのかな？ってのは気になりました。ECS使ったことないのでなんともですが。

Review appsは使いどころというか、条件がいまいちわかりませんでした。本番deployをmanualにして、stagingで状態を確認してからdeployってのはとてもいいと思いました。

最後、container registry付属ってのもとてもいいですね。docker-hubに出せないイメージもあるでしょうから、imageをbuild、登録して、それを展開してdeployしてテストするということができる。container registryは使ったことないので自分の環境で有効にしてみようと思います。

第7章 フィードバック

deployしたあとのパフォーマンス計測としてprometheusが内蔵されています。すごいな。

そもそもgitlabサーバそのもののメトリクスを収集できるようになるのはまぁわかるのですが、やっぱりdeployしたアプリケーションをどうやって監視するのかがわかりませんでした。

本書p243でもGitLabのOmnibusパッケージに付属しているPrometheusは、デフォルトでgitLabをモニタリングするためのメトリクスが設定されているため、アプリケーションのパドーマンスモニタリングに利用するのはおすすめできません。ここでは別途Prometheusを導入する方法を紹介しますって書いてあってなんだそれってなりました。

また、Cycle Analyticsでは各ステージの時間を計測できます。これも使ったことないですね。issueやMRの時間も計測されるみたいなので、GitLab Flowのブランチ戦略にしたがって運用する必要がありそうです。

issueが立ち上げられてから本番deployまでのそれぞれの時間が図れるというのだから、これはすばらしいフィードバックですよね。継続的改善のために必要な指標が簡単に得られる。

また、現在ベータ版で、10系から導入されたAuto DevOpsの紹介が簡単にされています。これは興味ありますね。ただ、kubernetesを別途用意しないといけないのかな？

おわりに

普段から毎日お世話になっているGitLabの最新情報がまとまった一冊。Git含め知識0の方から今すぐDevOpsがはじめられる一冊になってると思います。個人的にはデプロイまわりがまだ触れてないので、GitLabを今後も使い倒していきたいと思います。

みんなで強くなるチームビルディングを支える脱・属人化

はじめに

今日もポエムです。どうした。ポエムはいいからコードをかけ。そんな声は聞こえないようにして続けます。

なんで属人化をころしたいの

僕自身が強く興味を持っていることが属人化を殺す、ということなんです。なんでそれをしようと思っているかというと、子育てのため休職する先輩の穴を埋めるため異動してと抜ける当日に言われ、引き継ぎもクソもない状態で仕事をはじめることになった経験がでかいと思います。

一応、その最終日の午後にあきらめつつ会話したんですが、「僕が知ってることはリーダーさんが知ってるから大丈夫。僕しか知ってることはない。」と言って去りましたが、リーダーさんが知っていることはその担当の方の仕事の大局的な進捗だけで、実際のオペレーションレベルでは共有されるはずもありません。

別に異動になったときに引き継げばよくない？

だからその引き継ぎのコストがバカにならないんだってー！

この出来事があって以来、僕は引き継ぎを不要、つまりいつ自分が職場から抜けてもいい状態にする働き方を僕自身するようになりました。引き継ぎに一週間とか二週間とかかけてる現実がそこら中にありますからね。。。びっくりする。

そもそも引き継ぎ自体のコストがもったいないということと、人材流動自体が頻繁にあります。これが1年に1回ぐらいならまぁいいけど、そうはいかないでしょう。チームメンバーそのものの急な異動、転職は年に数回ありますし、発注先メンバの入れ替わりだって頻繁にあります。

(高いレベルの)技術的な属人化は存在しうる

とはいえ、技術的にその人しかできないことはあるべきであり、高いレベルになるとこれはどうしても存在すると思います。それがプロフェッショナルなんだと思います。僕が言いたいのはその高いレベルの属人化ではなく、笑っちゃうぐらい低いレベルの属人化です。

自分が一度経験して、最初はできなかったけどできるようになったことは、誰かが踏むかもしれませんね。トラブル解決のためのナレッジや、あるいは社内手続きのためのめんどくさい手順だったり、自分のために作ったちょっとしたスクリプトだったり、そういう細かいものをチームに撒いて、自分がいなくてもみんなができるように一手間かけてしておきます。

一度経験すればそのひとは5分で解決できても、初めて出会う人は30分、1時間かかるかもしれません。そういうコストを減らしたいですよね。

みんなで強くなるための委譲

自分しかできないこと、自分しか知らないことに出会ったら、それをすぐ、チームメンバー全員ができるように整備します。

また、自分が受け持っている短期、中期の仕事は、一定期間経ったら別にひとに委譲してしまいましょう。サーバ管理の仕事だったり、ビルド環境の仕事だったり。定型的な仕事は、最初は自分だけができるでいいですが、最終的には誰かに引き継げるようにしておきましょう。その手段が自動化だったり、ドキュメント化です。

ここがちょっとコツで、「自動化しろー！」ってのはよく言われますが、自動化するためには、メンバー自体の技術教育が必要であるということです。属人化をなくすためにはチームの平均レベル向上が不可欠で、この視点を飛ばして自動化してしまうと「誰もメンテできないよー！」ということになります。

「ドキュメント化」にしてもそうです。文章に書き記すスキルというのは実は誰でもできることではありません。アウトプットにもコツがあります。他者が読みやすいドキュメントを書くスキルも、誰もができることではありません。最初はあなたがテンプレートぐらいを用意して書きやすくして、少しずつチームメンバーのドキュメンテーションスキルを向上させる必要があります。

チームビルディング

ここまで書いてきて、脱属人化を志すことは、チームメンバー全員の底上げをする、チームみんなで強くなる行為に他なりません。

これまで、属人化を防ぐことによって、以下のようなものが蓄積され、誰でもできるようになります。

• 1度やった業務
• 定型業務

これをするとともに、自動化やドキュメンテーションを行うための技術力も底上げされます。

さらに、こうやって共通でぶつかる壁を徹底的に減らすことによって、全員が未知の問題にしかぶつからなくなります。つまり、全員がチーム内で唯一の存在になります。それにぶつかるたびにそれをチームメンバーにばらまいてまた底上げします。

こうしてチームの成長が加速度的に速くなり、みんなで強くなるチームになります。

おわりに

僕はこういった考えをもとにチームビルディングを行っています。そしてこれを行うために、いろんな方法で仕掛けをチームにばらまいています。そのコツは昨日書きました。

take-she12.hatenablog.com

普段から自分が強く意識していることを、一度文書化しておこうと思って書いてみました。まずはこの考え方をチーム内で共有することからはじめようと思います。

チームに変化を導入するときに心がけていること

はじめに

今日もポエムです。

本当は会社のアドレスで登録しているqiitaにこれを投稿しようと思ったのですが、プログラミングじゃない、ポエムは嫌われそうなので、こちらに書くことにしました。

きっかけは後輩くんとキャリア面談(笑)をしているときに、「なんで（たけさんは）いろんなあたらしいことを見つけて、チームに導入できるんですか」と言われて、自分なりにそのとき考えた答えをまとめておきたかったから。

そしてそれを後輩くんに伝えるためにqiitaに書きたかったんだけど残念。(笑)

何を変えてきたの

日常的に改善を行ってきたし、課題意識を持って変えてきました。

• 部/チームにmattermost(slackクローンOSS)導入 -> 今は部の1/3ぐらいがactive user、プロジェクトや開発環境管理にも活用
• プロジェクトにmattermost分報導入
• 障害チケットをmattermostに通知する仕組み導入
• 修正パッチ作成ツールをCI連携し全自動化
• 仕様書等のドキュメントレビューをgitlabのMRで行うように変更
• 週の進捗報告で前週との差分が見えるようgitで管理/報告
• OSS導入、活用推進
  • mattermost
  • knowledge
  • gitlab
  • ...ほか多数

残念ながら商用環境に対して何かを変えて顧客価値、ビジネス価値をもたらした、みたいなことはできていません。

自チーム、部に閉じた範囲では何も言われないので(笑)改善提案して、それを流行らせるってことは結構得意なほうだと思っています。

心がけていること

なんとなく書き出してみて、新しい仕組みの導入には以下の3フェーズがあるような感じがしてきました。

1. 自分一人で試す
2. チームに提案する
3. 少しずつ広める

それぞれのフェーズでコツがありますが、以下フェーズに絡めたり絡めなかったりしつつ心がけていることを紹介します。

変化は小さく、少しずつ

フェーズ問わず、今回変更しようとしている内容全体についてです。

開発運用ガチガチの組織にいきなりDevOpsじゃ、ansibleじゃ、と言っても無理ですよね。

wordとexcelでドキュメントを書いている組織にいきなり今時reSTで書いてCIでpdfにbuildするんじゃ！って言っても無理なわけです。

理想は小さく、少しずつ、段階を踏んで変えていきましょう。一番無理のないところから変えましょう。

まず、自分がやってみせる

1つめのフェーズです。

自分がやらないのに相手にやって、と言ってもなかなかやってもらえません。やり方を書いたとしても、です。

まず、自分が普段から使ってみる。それをチラチラと見せる。(笑)　なんかあいつやってんなーという雰囲気を作るところからはじめます。

自分が十分に使って、うわーすごいいいー！という空気を見せてから、具体的導入のための説明をします。

現在の課題を共有する

ここからは2番目の提案について。

改善したいということは、現状何かしらの課題を抱えているはずです。

今はどういう状況で、理想はどういう状況、だからこうしませんか？ということを明らかにして提案しましょう。

メンバーにとって何が変わるのかを示す

今まではこうだったのが、こうなる。変更点だけをシンプルに示すこと。

誰しもが「自分がやってる普段の作業はどうなるの？」が気になるはずです。その不安を埋めましょう。

それをするとどううれしいの？を示す

エンジニアっぽいですよね（笑）

その改善/変更をすることでどううれしいの？ということを示すのが大事です。僕の自己満じゃなく、みんなにとってもうれしいことなんだよ、ということを説明することが重要です。

新人を使う

自分も使ってみせたし、チームに提案もした。それでも全員がやってくれるまでは時間がかかります。3番目のフェーズですね。そこで使えるのが新人さんです。(笑)

いやらしいんですが、新人さんというのは今までやってきたやり方というのを持っていないので、新しくこれでやってみない？と言っても受け入れられやすいです。そしてその感想を聞くこともできます。その新人さんに（悪いけど）実験台になってもらって、その後チームに展開するということができます。

今ちょうど新人さんを見てるのもありますが、インターン生がきたときに新しい仕組みを試して、（mattermost）これはいける、と確信してチームの本格活用に展開した、ということもありました。

完璧を求めない

いざチームで導入が決まっても、それができていないメンバーがいたとしても責めてはいけません。つまり、ルールにしてはいけません。みんなが(強制されてないけど)なんとなくやっていることを変えるんです。この積み重ねが文化を作ります。

頑なにやり方を変えないメンバーがいてもいいです。少しずつ、少しずつ仲間を増やしていきましょう。

おわりに

改善のための変化には三段階あり、まず自分がしれっと使い始めて、メンバーに使って見せて、なんとなく認識させるという、1番目のフェーズが個人的にはとても重要だと思います。この期間をじっくり取らずにはじめると詰まってしまうことが多い。

そのあと、実際にこのメンバーならいける、という確信が得られたら、メンバーが集まる会で提案します。提案するときは「現在の課題」「導入して何が変わるか」「導入して何がうれしいか」を説明しましょう。そこでいいですか？と聞いてダメですという組織だと諦めてください。うちの上司は絶対にダメと言いません。

導入後も継続的にできているかどうかはじっくりフォローしてください。また、完璧を求めないでください。

今後も、プロジェクト/チーム内の課題を、技術を使って解決していきたい。

もうカタログを増やすだけの勉強は、やめた

はじめに

めずらしく読書記録でも、技術学習記録でもなく、ポエムであり、決意表明をする記事です。

きっかけ

転職活動中、ある会社とのカジュアル面談で、CTOの方と面談した。

CTOという肩書きの方と話すのがはじめてで、僕なりのその時点のCTOの役割は、技術をビジネス価値にするための責任を持つひと、だと思っていた。

転職活動中に考えたかったテーマ、"技術とは何か"について、自分の中で答えを持っておくべきだと思っていて、考えたかったことだった。

せっかくの機会なので、CTOという枠割のミッションや、技術とは何か、技術を高めるために必要なことは何か、ということをお話した。

CTOの役割

その方の答えは「技術を、企業成長、サービスの成長につなげること」で、必ずしも技術をビジネス価値、つまりお金に変えるとは思っていない、とのことだった。

さらに話を聞いた。

技術は問題解決のためのツール

エンジニアという人間は現実の課題、問題を解決してなんぼ。

問題解決にとにかく執着したという。

問題解決に執着することで、自然と技術がついてくる。問題解決への執着と、技術習得は両輪。

そう考えると、僕は、問題解決の量が圧倒的に足りないと思った。

技術だけを身につけること

技術ってなんだろう？の答えは置いておいて、技術知識だけを身につけて、問題解決をしないことは、カタログセットを持つだけで、エンジニアとして無価値だと思った。(これはこの話をしての僕の考えです)

前述するように、これは両輪で、問題を解決しないといけない場面に、自分の中のカタログがあればそれは心強いときもあるだろう。

でも僕は自己研鑽での学習を、問題解決に特につながるわけではないけど好きだから、興味があるから学んでいたことと、直近で困っているから解決するために学んでいることを、明確に区別できていなかったように思う。

そしてまわりの優秀なエンジニアは、問題解決のための技術学習を行っているなぁ、とハッとした。

これから

もうカタログを増やすだけの勉強はやめる。

問題を解決すること、みんながうれしくなることを実現に技術を使う。学ぶ。

開発業務の改善はしぬほどやってきて、問題解決をしてきた。今後はそれをベースに、プロダクト、サービス、ビジネス課題を解決できる領域に、僕は行きたい。

「イシューからはじめよ」を読んだ

はじめに

読んだ。

イシューからはじめよ―知的生産の「シンプルな本質」

評判もよかったということもあって、年始に読みました。が、ブログにあらためてアウトプットする時間が全然ないので読書メモという形で今回は記してクローズする。

読書メーターでの私の感想は以下。

各所で評判が良かったので読んでみたが、その通り良書でした。サイエンスとコンサルタント両方の経験がある筆者だから書ける考え方で、特に「分析」とは何で、どう見せるのか、という点についてはビジネスパーソンだけでなく、大学生/大学院生も読むべきだと思った。読み返して自分の仕事にどう当てはめることができるか再確認する。

bookmeter.com

以降はkindleのハイライトを順に追っていく。便利だなあ。物理本は最初からパラパラとめくって復習がしやすいけれど、特定箇所のマーキングが本に手をいれない限り難しい。逆に電子本は全体をパラパラめくるのは難しいが、ハイライトが素晴らしい。一長一短ですね。

「悩む」と「考える」の違いを意識することは、知的生産に関わる人にとってはとても重要だ。ビジネス・研究ですべきは「考える」ことであり、あくまで「答えが出る」という前提に立っていなければならない。

10分悩んでも解決しないなら1度休む。悩むことをするな、答えがある前提で答えに向かって考えろ、という最初の主張。「悩む」が自分の中で判断保留とも捉えられるので、答えを出せということですね。

それは「根性に逃げるな」ということだ。 　労働時間なんてどうでもいい。価値のあるアウトプットが生まれればいいのだ。たとえ１日に５分しか働いていなくても、合意した以上のアウトプットをスケジュールどおりに、あるいはそれより前に生み出せていれば何の問題もない。

どうしようもないときは根性に逃げがち。というか、せめて根性ぐらい出さないと、という考え方をしてしまう。本当によくないので反省。

プロフェッショナルとしての働き方は、「労働時間が長いほど金をもらえる」というレイバラー、あるいはサラリーマン的な思想とは対極にある。働いた時間ではなく、「どこまで変化を起こせるか」によって対価をもらい、評価される。あるいは「どこまで意味のあるアウトプットを生み出せるか」によって存在意義が決まる。そんなプロフェッショナル的な生き方へスイッチを入れることが、高い生産性を生み出すベースになる。

労働時間ではなく、バリューで答える、バリューでのみ評価される、そんな世界は怖いけれど、そっち側にいかないといけない。

問題に立ち向かう際には、それぞれの情報について、複合的な意味合いを考え抜く必要がある。それらをしっかりつかむためには、他人からの話だけではなく、自ら現場に出向くなりして一次情報をつかむ必要がある。そして、さらに難しいのは、そうしてつかんだ情報を「自分なりに感じる」ことなのだが、この重要性について多くの本ではほとんど触れられていない。

現場がすべてっていうのはいろんなところで言われてる気もします。まずはやってみる。マネジメント、リーダーといった実作業をしていないひとたちには本当の問題が何かわかりづらい。現場のつらさを救える働き方をしたいと思う。(ちょっとそれた)

「やってみないとわからないよね」といったことは決して言わない。ここで踏ん張り切れるかどうかが、あとから大きく影響してくる。

ウッ　言いがち。。。エンジニアリング、まず実験、まず動かすというのは大事な姿勢だが、ここは知的生産の場なので、それはダメだろう。

僕が「言葉にすることを徹底しよう」「言葉に落とすことに病的なまでにこだわろう」と言うと驚く人が多い。僕は「理系的・分析的な人間」だと思われているようで、そうした僕から「言葉を大切にしよう」というセリフが出ることが意外なようだ。

言葉にすることで、それが言葉として(一旦)確定される、というのは僕も普段から意識しています。明文化する、言語化する、技術文章であれば一意に取れるようにする。現在の課題も言葉にしてこそ共有される。言葉は大切。

人間は言葉にしない限り概念をまとめることができない。「絵」や「図」はイメージをつかむためには有用だが、概念をきっちりと定義するのは言葉にしかできない技だ。言葉（数式・化学式を含む）は、少なくとも数千年にわたって人間がつくりあげ磨き込んできた、現在のところもっともバグの少ない思考の表現ツールだ。言葉を使わずして人間が明晰な思考を行うことは難しいということを、今一度強調しておきたい。

思考はどこで行うか？という話がありますが、こうやって文章にしながら思考もできますよね。言葉にすることを諦めたら本当に試合終了だと思う。

分析の大半を占める定量分析においては、比較というものは３つの種類しかない。表現方法はたくさんあるが、その背後にある分析的な考え方は３つなのだ。このことを押さえておくだけで分析の設計がぐっとラクになる。では、この３つの型とは何だかわかるだろうか？　答えは次のようなものだ。 　１　比較 　２　構成 　３　変化 　どれほど目新しい分析表現といえども、実際にはこの３つの表現のバラエティ、および組み合わせに過ぎない

後半は分析方法について。「何がイシューなのか」を考え抜いて定めた上で、そのイシューをどう解決すべきかをデータを使って説得する、知的生産はこのシンプルな方法で行うという話でしたね。

脳は「異質な差分」を強調して情報処理するように進化してきており、これは脳における知覚を考える際の根源的な原理のひとつだ。そしてこれが、分析の設計において明確な対比が必要な理由でもある。明確な対比で差分を明確にすればするほど脳の認知の度合いは高まる。そう、分析の本質が比較というよりは、実は私たちの脳にとって認知を高める方法が比較なのだ。そして、私たちはこれを「分析的な思考」と呼んでいる。

分析とは何か？に着目したときに、必ず比較が必要ということですね。どちらかというと、ひとが「わかる」ために比較が必要、という話を聞いたことがあります。比較というか、自分が今まで経験して、知っていることと結びつけて理解するという話。それに少し近いのかな。

分析イメージを設計する際（第４章で詳説）には、同じような分析の型が続かないようにすることが重要だ。私たちの脳は異質な差分しか認識しないため、同じかたちのグラフやチャートが続くと、２枚目以降に関しては認知する能力が格段に落ちる。同じかたちが３枚続けば大きなインパクトを与えることは相当難しくなる。チャートの表現レパートリーは多くもち、極力同じかたちが続かないように工夫する。

ストーリーとしての、分析の続け方も、同じ方法を極力取らないことを強調。

ここで異なる情報をもった２つ以上のニューロンが同時に興奮し、それがシナプスでシンクロ（同期）したとき、２つ以上の情報がつながったということができる。すなわち、脳神経系では「２つ以上の意味が重なりつながったとき」と「理解したとき」は本質的に区別できないのだ。これが第３の特徴、すなわち「理解するとは情報をつなぐこと」という意味だ。

さっきの理解の話はここでしたね。

何度も情報のつながりを想起せざるを得ない「なるほど！」という場面を繰り返し経験していると、その情報を忘れなくなる。当たり前のように思えるが、これは日常ではあまり意識されていない。

これのもっと激しいのが「そういうことだったのか！」ってやつ。すっげー気持ちいいよね。

このようなカギとなるサブイシューを検証する場合は、どちらに転ぼうと意味合いが明確になるタイプの検証を試みるようにする。答えを出そうとしている論点を明確に認識し、右なのか左なのか、それに答えを出すのだ。

どっちに転んでも有益なイシューを選ぶこと。意識したことなかった。「できないということがわかった」ってやつだよね。

(自分の知識や技では埒が明かないときにどうするか？) もっとも簡単なのは「人に聞きまくる」ことだ。格好よく言えば「他力を活用する」わけだ。それなりの経験ある人に話を聞けば、かなりの確率で打開策の知恵やアイデアをもっているものだ。運がよければ同様のトラブル時にどのようにして回避したかを教えてもらえることもあるし、通常では手に入らない情報の入手法を聞けることもある。自分の手がける問題について、「聞きまくれる相手」がいる、というのはスキルの一部だ。自分独自のネットワークをもっているのは素晴らしいことだし、直接的には知らない人からもストーリーぐらいは聞けることが多い。

人に聞ける、人を頼れるのってかなり重要なスキルで、僕はこれが苦手だと自覚しています。聞きまくれる後輩くんうらやましい。。。

(リチャード・ファインマンについて) 「いわゆる天才とは次のような一連の資質を持った人間だとわしは思うね。 　●仲間の圧力に左右されない。 　●問題の本質が何であるかをいつも見失わず、希望的観測に頼ることが少ない。 　●ものごとを表すのに多くのやり方を持つ。一つの方法がうまく行かなければ、さっと他の方法に切り替える。 　要は固執しないことだ。

多くのやり方を持つことできるの、大事だなあ、普段から鍛錬しないといけない気がする。固執しないために必要。

１回ごとの完成度よりも取り組む回数（回転数）を大切にする。また、90％以上の完成度を目指せば、通常は途方もなく時間がかかる。そのレベルはビジネスではもちろん、研究論文でも要求されることはまずない。そういう視点で「受け手にとっての十分なレベル」を自分のなかで理解し、「やり過ぎない」ように意識することが大切だ。

真面目だからやりすぎてしまう。。。これも何が求められるレベルなのかをすり合わせないといけないと思う。まず早く出して、フィードバックをもらうことだね。

ひとつ、聞き手は完全に無知だと思え 　ひとつ、聞き手は高度の知性をもつと想定せよ 　どんな話をする際も、受け手は専門知識はもっていないが、基本的な考えや前提、あるいはイシューの共有からはじめ、最終的な結論とその意味するところを伝える、つまりは「的確な伝え方」をすれば必ず理解してくれる存在として信頼する。「賢いが無知」というのが基本とする受け手の想定だ。

今回の案件で、自分の案件の技術的なことについて、普段全然話さない他部門のひとに話してさっぱり伝わらなくて苦労した。相手の知識レベル、技術レベルがどうしてもわからなかった。ただ、事前知識を持たないという意味での無知と、適切な情報を与えれば理解はできる(極度にレベルを下げ過ぎない)高度な知性の想定は重要な視点だと思いました。

コンサルタントは高いフィーをもらう代わりに確実に変化を生み出し、クライアントに喜んでもらうのが仕事だ。科学者も限られた時間のなかできっちりと成果を生み出すのが仕事という点は変わらない。いずれも結果に対する強い自己ドライブがないと仕事を楽しめない。報酬は年棒だけで「時間外労働」という概念の一切ない世界においては、こうした考え方をしていないと最悪の場合、奴隷のような生活になってしまう。

コンサルタントと科学者の共通点。両方経験した著者ならでは。

「人から褒められること」ではなく、「生み出した結果」そのものが自分を支え、励ましてくれる。生み出したものの結果によって確かに変化が起き、喜んでくれる人がいることがいちばんの報酬になる。仕事がうまく進んだとき、僕が感じるのは「うれしい」というよりも「ほっとした」というものだ。自分の会社やクライアントに約束した価値を無事届けた、このこと自体が何とも言えない達成感を生む。 　この価値を生み出す根っこにあるのが、「イシューからはじめる」という思想であり、脱「犬の道」という考え方だ。これをしっかりともつだけで僕らの生活は格段にラクになる。そして毎日が格段に充実したものになり、一日一日で生み出す価値は遥かに大きなものになっていく。 　このことを最後に共有できたら、と思う。

人から褒められることも嬉しいけどね。出した結果でさらに褒められるといいよね。僕はまず自分のチームのために大事なことを生み出して、そしてビジネス価値を組織に出していく働き方をしていきたい。

おわりに

kindle便利やな。

「TeamGeek」を読んだ

はじめに

読んだ。たまたま訪問してカジュアルに面談したとき、とある部長さんが求める人材像のところで、HRTのくだりがでた。「TeamGeak」って読んだことありますか。と問われ、なかったので訪問後即購入。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

章ごとに内容を振り返っていく。

1章 天才プログラマの神話

まずこの章は「チームでうまくやること」の必要性について、いろいろな例をあげて説明されている。

天才は「チームとうまくやる」天才

やはりこの章で印象深い言葉はおそらく多くのひとと同じで以下だと思う。

だが、ちょっと待ってほしい。現実的に考えてみよう。君は天才じゃない。(p7)

天才とまではいかなくても、1人で十分に成果を出せる優秀なプログラマだと思ってるひともいるかもしれない。(僕はまったく思わないが)

仮に君が天才だったとしても、それだけでは不十分なんだ。天才だってミスをする。優れたアイデアやプログラミングスキルがあっても、開発したソフトウェアが必ずしも成功するとは限らない。今後のキャリアがうまくいくかどうかは、同僚たちとうまく協力できるかにかかっている。(p7)

スティーブ・ジョブズ、マイケル・ジョーダンといったスーパースターをあげ、誰もが"天才"というロールモデルを設定したがり、それになろうとする。だが実は彼らは「チームとうまくやる」天才だったのだ。

Linuxカーネルの作者リーナスの功績は偉大だが、何よりLinuxコミュニティを継続して発展させたことがもっとも偉大とされるのも同じだ。

プロジェクトのバス係数を減らせ

最近は「オープン」という価値観が広がってきているように（個人的には）感じるけれど、やっぱりみんな隠すよね。自分が書いたコード。見せたらいいのに。

素晴らしいアイデアを隠しておいて、それが完成するまで誰にも話さないというのは、リスクの高い大きな賭けだ。早い段階で設計ミスをしやすくなるし、車輪の再発明をする可能性があるし、誰かと協力するメリットが失われる。(p9)

トラックナンバーともいうが、プロジェクト内で何人バスに轢かれたらプロジェクトが破綻するかをバス係数という。つまり、自分しか持たない情報を作らないこと、すなわち常にフルオープンにしておき、いつ自分がいなくなってもいいようにしておくことが重要である。これにはとても同意する。なかなかできることではないらしい。自分が心がけていることのひとつ。（仕事はすべてgitにある。）

これに関しては今の職場ではかなりできていると思うし、自分が率先して進めてこれたと思う。mattermostによる個人部屋、分報の導入で悩みや業務内容をクリアにしたし、トラブル調査内容、ノウハウはチケットに記載すること、ツール類はcloneして使えるよう整えてgitに格納、などなど「引き継ぎに一週間必要です」が死ぬほど嫌いな僕が努力し、率先して実践し、勧めてきたのは正しいことだったと思う。

チームがすべて

ここは引用のみで。

ソフトウェア開発はチームスポーツである(p13)

さらに

隠れ家に1人でいたら、才能が開花することもない。秘密の発明をこっそり準備していたら、世界を変えることもできないし、数百万人のユーザーを喜ばせることもできない。誰かと一緒に仕事をしなければないけないんだ。ビジョンを共有しよう。仕事を分担しよう。他人から学ぼう。そして素晴らしいチームを作るんだ。(p13)

三本柱 - HRT

本書の主張はこれに尽きるといっても過言ではないと思う。

• 謙虚(Humility)
• 尊敬(Respect)
• 信頼(Trust)

この3つ。今のチームはこれがあるチームなので本当に恵まれていると思います。

2章 素晴らしいチーム文化を作る

DevOpsのくだりが記憶に久しいですが、「文化を作る」という言葉はちょっと取り扱いが危険です。行動の結果が文化になるので、文化先行だとダメだ、なんて意見も見たことがあります。

パンの喩えがあったので引用しておきます。

スターター(創業者)がパン生地(新来者)に菌(文化)を植え付ける。イースト菌と乳酸菌(チームメンバー)が発酵(成長)すると、おいしいパン(チーム)のできあがりだ。(p32)

パン作りしたことないのでわかりづらい。。。

が、どの会社も独自の文化を持つ。その文化を最初に作るのは、最初にいたメンバー(スターター)だろう。その後も文化は変化/成長し続ける。

チームの文化の定義・維持・防御に責任を持つのはチームメンバーだ。誰かが新しくチームに参加したときは、チームリーダーから文化を教えてもらうのではなく、チームメンバーから学ぶのである。'p34)

文化という言葉は何気なく使っているけどここで意味を再確認しておこう。

www.weblio.jp

① 〔culture〕 社会を構成する人々によって習得・共有・伝達される行動様式ないし生活様式の総体。言語・習俗・道徳・宗教、種々の制度などはその具体例。文化相対主義においては、それぞれの人間集団は個別の文化をもち、個別文化はそれぞれ独自の価値をもっており、その間に高低・優劣の差はないとされる。カルチャー。

ふむ。チームの行動様式ということですね。

その後はよりよいチーム文化の例を、コミュニケーション、議論、コードの観点で紹介されている。

3章 船にはキャプテンが必要

リーダーシップについて語られているのが本章。かなり注意深く「マネージャ」という言葉を使わないようにしている。役職上マネージャーというのは現在でもあるだろうが、そこは話題の外のようだ。実際、人モノ金を管理するマネージャーも、リーダーであるべきだし、それこそ後に出るサーバントリーダーであることが望ましいだろう。

サーバントリーダーとは、従来の「管理」するマネージャー（リーダー）と異なり、チーム全体を謙虚・尊敬・信頼の雰囲気を作り出すリーダーのことだ。

これはエンジニアでは対処できない社内の障害物を排除することかもしれないし、チームの合意形成を支援することかもしれない。あるいは、夜遅くなったときにチームに夜食を買ってくることかもしれない。(p69)

サーバントリーダーはチームにアドバイスを与えるだけでなく、必要であれば　チームが順調に進めるように穴を埋める。自らの手を汚すのがサーバントリーダーだ。サーバントリーダーが管理するのは、技術的な側面とチームの人間関係である。両方やらなくっちゃあならないってのが「サーバントリーダー」のつらいところだな（人間関係のほうが難しい！）(p70)

これもうちの上司はできていて本当にすごいなぁと思います。僕だったらメンバーに僕がいたら僕の仕事を信頼して任せられない（笑）

サーバントリーダーは最近だとマイクロソフトの牛尾さんが、ロッシェル・カップさんと共同でやられているのを見ました。

simplearchitect.hatenablog.com

アンチパターンはそりゃそうだよなーって感じなので目次だけ。

• 自分の言いなりになる人を採用する
• パフォーマンスの低い人を無視する
• 人間の問題を無視する
• みんなの友達になる
• 採用を妥協する
• チームを子どもとして扱う

面白かったのはリーダーシップパターンですね。うちのリーダー/マネージャーは本当に鋼の心というか、まさに「禅マスター」なんですよね。。。すごい。。。

たとえ何が起きても、どんなにひどいことが起きても、どれだけの惨事が起きても、彼は決してパニックにならなかった。彼はいつも片腕を胸に当てて、もう片方の腕でアゴを押さえ、問題の状況をエンジニアに質問した。(p79)

うまく（時にはジョークをまじえて）質問することで、パニックになるエンジニアを落ち着かせる質問をするという。うちのリーダー/メンバーは大規模障害でもとても落ち着いてるので本当にすごいと思います。。。

管理ではなく、"信頼"した上でどんどん委譲していくこと。大事ですよね。

リーダーシップパターンも目次を載せておきます。

• エゴをなくす
• 禅マスターになる
• 触媒になる
• 先生やメンターになる
• 目標を明確にする
• 正直になる
• 幸せを追い求める
• その他ヒントやトリック
  • 委譲せよ。ただしては汚せ。
  • 自分自身に置き換えようとする。
  • 事を新たてるときを知る。
  • カオスからチームを守る。
  • チームを空中擁護する。
  • チームのいいところをフィードバックする。

リーダーシップとして大切なことが詰まってる章です。何度も読みたい。

4章 有害な人に対処する

言葉にウッときそうだが、チームを破壊するような"振る舞い"を排除することをだと、注意深く説明されている。

大切な"良いチーム文化はどのように守られ、継続され、必要に応じて進化していくかというと

文化が長続きしているのは、高い基準を設けているからではなく、その文化が自己選択的だからだ。素晴らしい人たちは、素晴らしいコミュニティに惹きつけられるのである(p101)

有害な振る舞いからチームを守るためには、ミッションステートメントを決めて、文化を強固にしておくことが大切だ。

どんな振る舞いが有害かというと、目次を貼っておく。

• 他人の時間を尊重しない
• エゴ
• 権利を与えすぎる
• 未熟なコミュニケーションと複雑なコミュニケーション
• パラノイヤ
• 完璧主義

そのひとが意図しているしていないに関わらず、プロジェクトの生産性の影響を与えることですね。

このあと追い出し方まで丁寧に書かれています。この章はどちらかというとオープンソースコミュニティの運営に役立ちそうな章だと思いました。

有害な人を追い出す、の目次貼っておきます。

• 完ぺき主義には別の方向性を示す
• 生命体にエサを与えない
• 感情的にならない
• 不機嫌の真実を探せ
• 優しく追い出す
• 諦めるときを知る
• 長期的に考える

最後にも注意があり、多くのひとは望んでプロジェクトに不利益を出しているわけではない。

無能で十分説明されることに悪意を見出すな(p116)

よくわかっていない人をプロジェクトから追い出すことが君の仕事ではない。破壊的な振る舞いを受け入れず、HRTに対する自分の期待を明確にすることが君の仕事だ。そのためには、その違いを理解する頭と実際に行動するスキルが必要である(p116)

継続して健全なチーム文化を守るためには必要なことですね。

5章 組織的操作の技法

この章はチームや、コミュニティから少し枠を超えて、組織という少し大きい単位での悪い例(悪いマネージャ、悪い組織)をあげ、それに対する切り抜け方が乗っている。気になった節のメモだけ。

許可を求めるより寛容を求めるほうが簡単

まずは組織で許されていることを把握しよう。許可を求めると責任を押し付けることができるが、逆に「ダメ」と言われる可能性もある。上司の許可を得なくてもできる範囲を知ることが重要だ。ただし、可能なかぎり会社にとって正しい事をしよう。(p132)

これ本当その通りだと思います。現在は寛容な部なので助かっている。。。

道がないなら道を作る

会社でチャンスを作るもうひとつの戦略は、草の根レベルでアイデアを受け入れてもらうことだ多くの人にアイデアを受け入れてもらったり、プロダクトを使ってもらったりすれば、たとえ官僚組織であってもつぶすことはできない。マネジメントもそのことに気づかざるを得ないので、受け入れるか抵抗するかになるだろう（抵抗すると政治資本が必要になる！）。これは多くのエンジニアが長年使ってきた戦略だ。たとえば、毎日の仕事が楽しくなるように、オープンソースツールをこっそり取り入れるのである。(p133)

これもやってますね、別に戦略的にやってるわけじゃないんですが（笑）

上司の管理方法を学ぶ

「マネージャーをマネージせよ」とはよく言ったもので、自分のためにうまく伝えよということである。

君が「うまく」やっていることを上司やチームの外部にいる人たちに知らせる必要があるということだ。

ここで「攻撃的」な仕事と「防御的」な仕事がでてくる。プロダクトのローンチという政治資本の増加につながる仕事は攻撃的な仕事で、リファクタリングや保守といったものが防御的な仕事。防御的な仕事も大事だが、その割合は全体の1/3〜 1/2になるようにせよとアドバイスがある。とはいえ大きい企業だと「攻撃的」な部と「防御的」な部になってしまいがちだが。。。

運と親切の経済

運は親切によって強化することができるという話、面白いと思いました。

自分の仕事に関係がなくても、他の人の仕事を手伝うようにすれば、その人から恩返しされる保証はないが（もちろん「しっぺ返し」もないが）、いずれ誰かが喜んで手伝ってくれるようになる。(省略)親切の経済で少しだけ信頼を稼ぐことができる。この信頼は掛け金のようなものだ。

6章 ユーザーも人間

最後に作ったプロダクトを使うユーザーについての章。ユーザーにとって使いやすいソフトウェアを作りましょう、ユーザーに対して良好な関係を築きましょう。ここでもHRTが出てきますね。

マーケティング ソフトウェアがどのように見られるかに気を配ろう。それによって、ソフトウェアを使ってもらえるかどうかが決まる。 ユーザビリティ ソフトウェアが簡単に試用できなかったら、遅かったら、使いにくかったら、アクセスできなかったら、ユーザーは立ち去ってしまうだろう。 顧客サービス ユーザーとの長期的な関係構築が、ソフトウェアの進化やユーザーの定着に影響を与える。(p177)

プログラマの仕事には中断がいっぱいだ。(中略) ソフトウェアを書く理由を簡単に忘れてしまう。そのソフトウェアは君のためではない。チームのためではない。会社のためではない。ユーザーの生活を豊かにするためである。ユーザーがプロダクトについて何を考えているか、何を言っているか、何を体験しているかに注目することが、長期的に重要なことになる。ユーザーはソフトウェアの成功に欠かせない血液だ。自分でやったことは、すべては自分に返ってくる。

おわりに

付録でも言っているが、本書で述べられていることはソフトウェアに限った話ではなく、あらゆるコミュニティでHRTが重要であり、あらゆる問題はHRTいずれかの欠如によって起きるものだとしている。その通りだと思う。

その認識をもとに、あとの章で語られているサーバントリーダーシップ、有害なひとの排除、組織を有効に活用すること、ユーザーを大切にすることはそれぞれ適した場面で役にたつだろう。その折に読み返したい。

「エキスパートのためのMySQL運用＋管理トラブルシューティングガイド」を読んだ

はじめに

読んだ

エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド

業務ではMariaDBを使っているが、正直MariaDBとの差を明確にわかって使っているわけではない。しかし、トラブル時も調査の方針、方法などはMySQLのものも参考になると思い、購入。

ただし、全部は読んでない。自分の中にインデックスをつけるのが目的。

第1章 MySQLの概要

その名の通り概要です。MySQLのことをよく知らないひとでも安心できる、親切設計ですね。不足している方は読んでおいたほうがいいでしょう。

5.7本でもこの手の解説はありましたね。

詳解MySQL 5.7 止まらぬ進化に乗り遅れないためのテクニカルガイド (NEXT ONE)

take-she12.hatenablog.com

また、構造的な特徴について興味がある方はさらにこちらを見るといいとのこと

詳解MySQL

プラガブルになっていてストレージエンジンを変更できることや、レプリケーション機能について記載しています。ディレクトリ構造やシステムデータベースの内容も丁寧に解説されています。my.cnfの設定解説と設定例までついてるので、1章だけでも相当詳しい内容ですね。。。

タイトルに運用/管理とある通り、この章でも堅牢に運用するためのTipsが乗っています。

1. mysql_secure_installation
2. DNSへの問い合わせを取り除く
3. (clientが同一ホストにいる場合)TCP/IPを使用しない 4.(クラッシュリカバリのために)バイナリログを有効にする
4. (オーバヘッドになるような)クエリキャッシュを利用しない
5. メモリのサイジング
6. ディスクキャッシュに関する注意点
7. InnoDBにおけるディスク関連のチューニング

さらにインストール時のよくあるトラブル対策まで。。。見事な1章だ、これ1冊で本になれるぐらいですね、さすが。。。

第2章 開発時のおける問題

文字化け

MySQLの文字化け/文字コード問題は私もMariaDBでぶつかったことがあります。p112の図2-1はよく覚えておきましょう。

         1     2          3,4  5
client ---> session ---> table--->filesystem
       <---         <---      <---
         6

1. 送信するSQL文の文字コード
2. クエリの実行に利用する文字コード
3. データを蓄える際の文字コード
4. テーブル名やカラム名に対する文字コード
5. ファイル名を解決する際の文字コード
6. クエリの実行結果に対する文字コード

それぞれで文字コードを設定可能で、異なる場合はMySQLが変換してくれるようです。しかし、統一したいですね。。。

p126、データがlatin1で格納されてしまっている問題、出会いました。。。

幸か不幸か、latin1文字コードを接続文字コードとテーブルの文字コードの両方で使用している場合、マルチバイト文字をそのまま格納することができてしまいます。(latin1はシングルバイトなので、ちょうどでコードされたような形でデータが格納されてしまいます)

MySQLのデフォルトの文字コードはサーバ側もクライアント側もともにlatin1なので、文字コードの設定が抜けていても、上記のように、問題なく日本語の入出力ができてしまいます。そのため、設定が抜けていることに気づいてもらえない、かわいそうなMySQL Serverが世の中にはたくさん存在していることでしょう。

いるやろなぁ。。。

以下の問題が発生します。

• 称号順序が狂ってしまう(latin1_swedish_ciを用いて1バイトずつ比較されてしまう)
• 本来の文字コードを指定して接続すると、文字化けしてしまう

特に後者の問題は、システムの刷新に伴うデータ移行などをする際に発覚することが多いものです。

まさにそれだった。。。

アプリケーションを含めて、1番最初に設定しておくべきですね。

MySQL CLI上のエラーを理解する

MySQL CLI上でのエラー対処の方法です。大前提として、3つのレベルがありますね。

• ERROR 重大なエラー。SQL文が実行できなかったことを示します
• WARNING 影響度が大きいエラー。SQL文は実行できたが、何らかの副作用があり、要求を完全に満たすことができなかったことを示します。
• NOTE 補足的なメッセージ。SQL文の実行には問題ありません。

多分、log_levelの設定値で、errlogにどこまで出すかを設定できるはずですが、SHOW WARNINGSコマンドで直近(直前？)のSQLのwarningが見れるようですね。

おもしろいのが以下

SHOW WARNINGSコマンドを利用してエラーメッセージを表示する際に気をつけなければいけないのは、SHOW WARNINGSコマンドが保持する渓谷の内容は直前に実行したSQL文のものだけだということです。(最悪のパターンは、SHOW WARNINGSのスペルを間違ってしまうことです)

やっぱり直前のみなんですね。

よく、ストレージエンジンのエラーとしてまとめられるのをみますが、perrorコマンドっていうのがあるんですね。はじめて知った。

ERROR 1030(HY000): Got error 139 from storage engine

に対して

shell> perror 139
MySQL error code 139: too big row　（行のサイズが大きすぎるよ！9

エラーコードの意味を教えてくれるんですね。

トランザクション

ACID特性と分離レベルについての解説がまずあります。

そして高度なトランザクション時のトラブル事例が乗っていますね。ロストアップデートとか、クラッシュ時のエラー回復など。

SQLモード

SQLに対して、どのような尺度で受け入れるのか、切り捨てるのか、エラーにするのかを決定する変数群のこと。これがバージョンによってデフォルトが違ったりするからこの概念を事前に知っておくのは重要。

アプリケーションによるエラーハンドリング

アプリケーション(client)側からみた、MySQLがエラーとなったときどのような例外にすればいいかが記載されています。重要だ。。。！

各言語ごとの補足方法、クラスも書いてあって親切だー！今のところアプリと1から書く経験に出会えていませんが、そのときは参照したい。

第3章 MySQLの状態を見る

SHOWコマンドとINFORMATION_SCHEMA

SHOWコマンドとINFORMATION_SCHEMAは同じ情報源から情報を取得してるんですね。

SHOWコマンド

SHOW VARIABLEやSHOW STATUSは普段から使ってます。特にSTATUSはどのようなものがあるか知っていたほうがいいですね。

よく見るのはConnectionでしょうか。handler〜はストレージエンジンに対しての捜査が行われた回数のようです。累積なのかな。定期的に取得することでどのぐらいの書き込み量があるのかがわかりそうです。

connectionについてはMax Used Connectionが最大風速を記録してるので便利ですね。

SHOW TABLE STATUSはテーブルごとの各種情報(例えば文字コードとか)を引き出すのに使えそうです。COLUMNS、INDEXも同様です。

レプリケーションをするしないのかかわらず、binlog出力する場合はSHOW BINARY LOGSはかなり使いますね。レプリケーション関連はMySQLのレプリケーションを使ってないので飛ばしました。

SHOW CONTRIBUTORSってコマンドもあるんだ、面白いね。

INOFORMATION_SCHEMA

すべての情報はこのテーブルにあるようですから、SHOWコマンドでとれる情報も元はこちらにあります。

細かく取得したかったり、SHOWコマンドで望み通りの形式で取得できない場合はこちらからとってくればいいでしょう。

SHOWコマンド廃止論もあるようですが、まだSHOWコマンドでしか取れない情報があるようです。

EXPLAIN

効率の悪いクエリを調べる時に使用します。今の所そのシーンに出くわさないのでスキップ。

プロファイリング

EXPLAINがクエリに実行計画であることに対して、プロファイリングはクエリがどのように(実際に)実行され、どのようなリソースが消費されているかがわかるツールです。

変数profilingで有効にし、クエリを実行したあと、SHOW PROFILEで実行できます。簡単ですね。

これもEXPLAINと合わせ、性能改善等でクエリを調べる時にまた見返したいと思います。

MySQLのログ

大事な6つのログ。復習しておきましょう。

• エラーログ
• バイナリログ
• 一般クエリログ(generallog)
• スロークエリログ
• トレースファイル(MySQL server本体をデバッグするときに利用)
• ストレージエンジンが作成するログファイル
  • 上記のログと混同しない、WAL概念におけるログ。

InnoDBモニタ

これまではMySQLレイヤでの情報収集方法でした。InnoDB(ストレージエンジン)レイヤではより詳しく情報を取得できます。

SHOW INNODB STATUSコマンドを実行したことがない人は、いないでしょう。

はい。

本当によく見るし、負荷があがってきたり、待たされてるクエリが増えるとエラーログに急に吐き出してドキッとするよね。

しかしこの本に詳しく解説があったとは、もっとはやく知っていたかった。次トラブル起きた時にみよう。。。

テーブルモニタ、テーブルスペースモニタも、特定のテーブルで問題が発生した時に役立ちそうですね。

システムの状態を調べる

MySQLではなく、OSレベルでの調査コマンドについて解説されています。親切だ。。。！

システムの状態を知る

• uname(OSのタイプ)
• df -h(ディスク情報)
• ps(プロセス)
• stat/file/fuser/lsof/strings/nm(ファイルやディレクトリ)

システムリソースを調べる

• free(空きメモリ)
• vmstat(メモリ使用情報)
• top(CPU/メモリ使用状況)
• ipstat(ディスクI/O状況)
• netstat(NICごとの統計情報)
• sar(システムの統計情報を詳細に調べる)

ネットワークを調べる

• ifconfig
• netstat
• traceroute
• nslookup
• ping

プロセスのメタデータを格納する/procディレクトリ

• /proc/cpuinfo(CPU情報)
• /proc/meminfo(メモリ使用状況)
• /proc/sys/fs/file-max(システム全体で同時にopenできるファイル数)
• /proc/sys/fs/file-nr(現在openされているファイル数)
• /proc/sys/kernel/threads-max(システム全体で同時に作成することができるスレッド数)

上記はシステム全体ですが、これらはプロセスごとに調べることができます。知っておくべきですね。

第4章 DTrace

はじめて知りました。Solaris、Mac OS X、Free BSDで使える、システム追跡ツールのようです。今のところLinuxメインなので使う予定はありませんが、存在は知っておきます。

D言語もはじめて知った。。。！

https://ja.wikipedia.org/wiki/D言語

第5章 運用中に起きる諸問題

レプリケーション

MySQLのレプリケーションに関する問題なので、(現在使ってないこともあり)スキップ。

MySQL単体のトラブルより、レプリケーションのトラブルのほうが多そうです。トラブル事例は役に立ちそう。

また、レプリケーションを堅牢にするためのテクニックは、他のレプリケーション(クラスタ)システムを使っていても同様のことが言えそうです。羅列しておきます。

• マルチマスターレプリケーションを利用しない(そもそも安全じゃないよ)
• スレーブを更新しない(当たり前ですね。。。)
• 適切なモードを選ぶ(レプリケーションモードのこと。行(ROW)ベースかSTATEMENTベースかMIXか。ROWが好ましいかな。
• テーブルにPRIMARY KEYを付ける(RowBaseのReplicationでは必須)
• バイナリログを同期する(ディスクとbinlogの同期)
• ハードウェアと設定、バージョンを合わせる(マスタだけ豪華にするのは好ましくない)
• スレーブを複数用意する
• 一度に大量の更新をしない
• 負荷分散に対応した接続方法を利用する
• 堅牢なネットワークを利用する(信頼性の高いネットワーク)
• テンポラリテーブルを使わない
• 監視する

クラッシュ

MySQLのクラッシュが起きてしまった時の対処について。workaroundとして回避するか、ソースコードを修正するの2択がある。

(OSやハードではなく、)MySQL自身の問題によってmysqldがクラッシュしてしまった場合、その原因の99.999%はMySQLのバグによるものです。

つまり使用方法によって起きることはほぼないってことですかね。

特定にはOSと、MySQLのソースコードレベルの深い知識が必要そうです。

• シグナル
• スタックとレース
• コア解析(GDB)

クラッシュリカバリ

InnoDBのクラッシュリカバリだけ見ておきます。

InnoDBのWALの仕組みの解説から。こういうところが新設だよね。

InnoDB(MySQL)を含む多くのRDBMSではWALの仕組みが搭載されています。ログとテーブルスペース両方に書き込むことによって、少なくともいずれかには書き込まれている状態にすることでクラッシュ時にも自動でリカバリする仕組みです。すばらしい。

さらに堅牢にするためのダブルライトバッファ、MVCCのためのロールバックセグメンとなど、クラッシュリカバリの説明の章ですがInnoDBの基本的な用語と動きが丁寧に解説されています。素晴らしい。

テーブルスペースが壊れていないかの確認のためにダブルライトバッファがあり、リカバリのためにログがあるって感じですかね。

テーブルの破損

万が一破損してしまった場合の復旧の手引き。REPAIR TABLEやinnodb_force_recoveryの紹介があります。

p373にあるバージョンアップよる照合順序の修正が怖いですね。mysql_upgradeか、ALTER TABLEで救えるのか。

性能の低下

まずスロークエリログで遅いクエリを特定したのち、改善計画について説明されています。頼もしい。

• ハードウェアの増強(スケールアップ)
• レプリケーションによる負荷分散(スケールアウト)
• Shardingによる負荷分散
• memchaced

ハードウェア障害

コンピュータの代表的なパーツが壊れたときの対処法を以下に紹介します。

ネットワーク、CPU、メモリ、ディスクとそれぞれ壊れた時の対処法が載っています。

第6章 堅牢な運用を実現するために

バックアップとリストア

これ超大事ですね。基本的な使い方を押さえておかないと、結構難しいのです。--single-transactionをつけないでロックになっちゃって痛い目にあったこともあります。。。

mysqldumpだと、リストアに時間かかるのが難点。フルダンプ＋binlogによる差分dumpを使ってうまくリストアするのがよさそうです。ロールフォワードリカバリーは便利。もっとはやく知っておきたかった。

ちなみにPerconaのXtra Backupはmysqldumpより早いらしい。いいなあ。表6-1の比較表もうれしいですね！

High Availability

p410 表6-2がクラスタソフトウェアの巨大な比較表です。すげえ。。。HAクラスタにもデータをシェアすつタイプと、シェアしない、シェードナッシングタイプがあっていろいろですね。

ネットワークの冗長化についてもMySQLレベルの話ではないですが記載されています、(Link Aggregation) 確かに、接続ネットワークが切れては話になりませんしね。

あとは使ったことないですがMySQL Clusterですね。確か有償？

セキュリティ

商用で使う場合はセキュリティが必須ですね。不正ログインを防ぐように適切な権限設定をしたり、SSLで暗号化したり、SQLインジェクション対策したり。重要。

アップグレード

これも誰しもが運用中ぶちあたる問題ですね。これももっとはやく見ておきたかった。。。大事な文言があります。

よく「新しいバージョンにはバグ修正によって新たなバグが含まれていることがあるのでアップグレードはしない」というシステム管理者がいますが、これはナンセンスです。もし、新しいバージョンでいくつかのバグが修正されていることがすでにわかっているならば、道のバグの可能性を含んでいる新しいバージョンよりも、既知のバグが確実に修正されている新しいバージョンのほうが安定していると考えるべきです。(p471)

すべてのオープンソース・ソフトウェアに通じる話ですね。

どのようなときにアップグレードすべきかは大事な考え方ですねー。

アップグレードの概要(計画)はぜひ参考にしてスケジュールを組みたいところです。すばらしい。

MySQL(MariaDB)のupgradeが骨が折れる作業であることは、身をもって体験しました。。。

アップグレードをしても安全かどうか？アプリケーションや運用への変更はないかどうか？ということを知るためには、そのアップグレードによってどのような変更が起きるのかを把握する必要があります。そのためにはMySQLの変更履歴に目を通して、現在のバージョンから最新のバージョンに至るまでに行われている「非互換の変更(Incompatible Change )」や「既知の問題(Known Issue)」について目を通さなければなりません。現在のバージョンとアップグレードしたいバージョンに開きがあると、そのような変更点が多く、確認には少し骨が折れるかもしれません。

骨折れる。

アップグレード作業のところには

アップグレード作業の本質はパッケージの入れ替えです。パッケージの入れ替え自体は至極単純な作業ですので5分とかからないでしょう。しかし、作業の安全性を高める目的やバージョン間での仕様変更の影響により、前後でその諸々の作業をしなければなりません。

ダウンタイムを最小限にするための、レプリケーションを利用したアップグレード(p482)では、原則が記載されています。

• 原則1：低いバージョンのマスターから高いバージョンのスレーブへのレプリケーションは可能。逆は不可。
• 原則2：メジャーバージョンの差は1つまで

結論は、商用と同じ環境で、upgradeテストとその後のアプリケーションのQAテストをしろ、に限りますね。

ストレージエンジンに非互換があり、SQLでは問題ないにせよ性能が劣化することがあるので、やはり1バージョンずつ、そしてmysqldumpによるdump/restoreが現実的だと思います。1秒も落とせないサービスにMySQLを使うのは難しいですね。

第7章 ソースコードのビルド

ソースコードのビルド方法と、QAテストの方法が乗っています。ビルドをする予定は当面なさそうなのでスキップしておいて、QAテストのところをみておきます。

MySQL Test Frameworkというものが付属されてるんですね。知らなかった。。。いずれにしてもこれはMySQLのコードに手を入れるときに使うものですね。

ベンチマークツールはそうでないひとも使う機会があるでしょう。mysqlslap、sysbench、DBT-2が詳解されています。このへんは実践ハイパフォーマンスMySQLのほうが詳しいでしょう。

実践ハイパフォーマンスMySQL 第3版

take-she12.hatenablog.com

おわりに

さすが奥野先生、インデックスつけるためにパラっと見るだけのつもりが、半日かかった、本当に詳しい、そして頼もしい本です。MySQLはオープンソースで、信頼性の高いデータベースですが、その運用には確実にスキルが必要です。この本をそばに置いておけばトラブル時にかなり役にたつと思います。