qpstudy 2016.04 でITインフラ監視の今後について発表しました #qpstudy

LINEで送る
Pocket

昨日は、qpstudyというITインフラの話題を中心に取り上げる勉強会で、ITインフラ監視の今後について発表してきました。

発表内容について

「ITインフラ監視の今後を考える」と題して、発表しました。

今回は「こうだからこうだよね」という感じではなく、この後に密かに予定されていたグループディスカッションのための種まきをするべく、会場の皆さんと課題を共有する目的でお話ししました。ですので、結論があまりないふわっとした発表のように聞こえた方もいたかもしれません。

会場の中でいろいろお話を聞いていくと、課題に掲げた内容で、いろいろ悩んでいる方が多いのだなという印象を受けました。例えば、今の業務に追われてしまっているのかなと感じる方もいらっしゃいました。

後のグループディスカッションを聞いていると、グループの方々が意図されたかどうかはわかりませんが、投げかけたテーマが織り込まれた状態で議論が繰り広げられていました。今回、一定の役割は果たせたかなと考えています。

グループディスカッション

今回のqpstudyは、Outputしていこうという目的のもとに、グループディスカッションが行われました。人数が多い勉強会というと、どうしても受け身になってしまうところがあります。そこを、どんなことであれOutputすることで、今日のことを一人一人が自分の価値に転換してもらえたら、という運営の皆さんの想いがあってのものだったようです。

私がいたグループ11は、「体系化」をテーマに話をまとめました。「レガシー(ここでは特に負の遺産)」と「経験」は背中合わせの関係であるけども、そこから抽出される物事がモデリング・構造化されることによって監視の知見が明文化・共有できるものに転化できる。その転化の方法として、学術論文や学会の研究会発表といったアカデミックな手法が参考にすることで、業界全体に知見を共有できるのではと考えられるのではというものでした。また、最近の若い人は修士号またはそれ以上を持っていることも少なくなく、そういった若い人に知見の体系化を担ってもらえればいいのではという意見を提案しました。

IMG_3317

各グループの発表は、チームによって、焦点を当てている事柄が違っていて大変興味深いものでした。例えば、監視のしかたをどうするか、実際に業務で困っていることの共有、自動化をどのように推進するかなど、様々なものがありました。私が印象に残ったのは、「重要な監視項目とは何か、それは誰にとって重要なのか。」を議論していたグループでした。技術者だけですとどうしても技術者に偏った意見になりがちだけれど、ステークホルダーとなっている別の業務担当にとって重要なことが見落とされていることがあるのではないか、というものでした。私は、レポートラインを洗い出すことで、誰にとって重要なのかの「誰」の部分を適切に洗い出せるのではないか、その上で「誰」にとって良いものかが考えついたり相談できるのではと考えています。

感想

監視の設計や実装は、私が以前執筆した「ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)」である程度体系化したのでやり方のモデルは一定の結論が出ていると考えているのですが、実際の運用であったり、組織の中でどのように立ち居振舞うかについてはなかなか答えが出ない悩ましい問題だと改めて感じました。また、自社サービスで監視業務を行っている人は、孤独な人がまだまだいることも、以前同じ境遇にいたことを思い出して辛い気持ちになりました。

今回、グループディスカッションを通して、知見はもちろん、悩んでいるのは自分だけではないということが共有できたことで、少しでも孤独感を軽減できる機会になれば良いなと思いました。そうすることで、今の問題を解決するモティベーションが上がればいいなと応援したくなります。

あと、監視の業務をはじめITインフラの業務を減点法で評価されてしまう悩みもあるなという話がありました。これは、加点で評価される仕組みを自分たちで積極的に考えて提案し、導入してもらうことで解決できないかと考えています。例えば、パフォーマンスを向上させてより多くの負荷に耐えられるようにしたり、運用コストを軽減して同じ人数で支えられる業務量を増やす、などです。または、GoogleのSREではありませんが(See also: Error Budgets and Risks | USENIX, Google – Site Reliability Engineering)、Error Budgetという考え方を導入して、挑戦の中で発生する一定の問題発生は許容してもらうような仕組みがあってもいいかもしれません。

いずれにしても、監視業務は多くの組織でまだまだ改善できる余地があって、そのための知見をどんどん共有・活かす場を作っていくことが今後のITインフラエンジニアの幸せにつながるのではないかと、考えているところです。

運営の皆様、大変お世話になりました。どうもありがとうございました!

LINEで送る
Pocket

転職して試用期間が間もなく終わる

LINEで送る
Pocket

1月からメルカリに転職して、サーバサイド(API)の開発担当として仕事をしています。試用期間が3ヶ月でして、それも間もなく終えられるところです。そこで、記録として今の状況を残しておこうと思います。

これまでと変わったところ

職種が変わった

前職はITインフラに関する仕事が主でした。開発もしていましたが、どちらかというとサーバの構築・運用が主軸となる仕事でした。そこから変わって、というか数年前までやっていたサーバサイドの開発担当に戻りました。ITインフラ関連の仕事も楽しかったのですが、今回それなりの規模の開発担当者ができる機会に恵まれたので、ぜひやってみたかったのが一番でした。また、エンジニア35歳定年説ではありませんが、プログラマを主たる業務として活動できる最後の機会かもしれないと考えたのも一つあります。

現職では主にPHPを利用していますが、現代のPHP 5.6にあった開発にあわせるのに結構苦労しています。というのも、自分の知識はPHP 5になったばかりの頃で止まっていたこともあり、随分とやり方が変わっていたのです。また、テストをきちんと書かれる方も多く、今まで自分がいかにテストの書き方が甘かったのかを痛感することもあります。

そんな中ですが、職種を変えいろいろ慣れないところもありつつも、なんとかやっているというのが現状です。

仕事の割り振り方が変わった

これまで、自分の仕事の範囲は「今ある仕事ではカバーしきれないところ全て」というものが多かった気がします。これは組織の中で新しいことに挑戦する良い立場であると同時に、やり方を間違えるとあいつは何をやっているのだと干されてしまう立場でもありました。

打って変わって、今は「あなたの役割はこれで、今のタスクはこれ。」とかなり明確です。タスク自体に工夫の余地はもちろんあるのですが、ここまではっきりとした仕事の割り当ては本当に久しぶりです。多分、新卒で働いていた大手企業以来です。

おそらく、自分自身の組織の中での立ち位置がわからなくなることは多分ないと思います。ただ、何もしないと埋もれてしまうかもしれません。

これはいいなと思った会社の仕組み

メンター制度

入社1ヶ月目には、すでに勤めている同じ職種の人がメンターとして割り当てられ、メンターの指導のもと仕事に慣れていく仕組みが整っています。転職したてのときは、ドキュメントの整備状況そのものの理解、組織としての仕事の流れ方、そしてドキュメントではカバーしきれないことをいかに早く理解するかはなかなか悩ましい問題として付きまといます。また、組織としても新入りの人に早く慣れて欲しいところです。そこをスムーズに進めるために、メンターをつけて支援するというのは素晴らしい仕組みだなと感心しました。

また、メンターをはじめ全ての人が、自分では「しょうもなそうで聞くかどうか悩む…」ような質問でも、快く対応してくれる状況にあります。仮に、わからないと「わからない」と言われるか「〇〇さんが知ってるはず」と促してくれることもあります。これで、自分が知らないことを無理なく確実に減らしていくことができました。質問しやすい環境があることを大変感謝しています。

シャッフルランチ

月に1回、会社が決めた数名のグループ、それも普段仕事でつながりがなかなか持ちにくい人たちと、会社持ち(限度額あり)で一緒に昼食を食べに行ける、シャッフルランチという制度があります。会社の規模がそれなりであること、そして今も結構な数の人が毎月入社されることもあり、あまりつながりがない人がどうしてもできてしまいます。そんな中で、シャッフルランチを通じて、どういう人がどんな仕事をしていることを知ることで組織がどのように成立しているかを知り、また会社の中で新たな人のつながりを作ることができます。

ほかの会社でも、組織が大きくなって、部署ごとのつながりが疎になりはじめたら、取り組んでみるとよい仕組みかもしれません。

今の状況

無理なく働ける

創業から3年強しか経過していないスタートアップ企業と聞くと、どことなく残業が多い大変な会社ばかりではないかと想像される方もいるのではないでしょうか。私も面接前にはその辺を心配していました。しかし、面接の際にそこまでではないことを聞き、実際にも自分を含め多くの人が無理なく、家庭やプライベートを大切にできる程度に働けています。おかげさまで、様々な面で充実した毎日を送ることができています。

優秀な人が集まっている

僕の感覚では、技術・経験が豊富で人柄もよい「大人」ばかりが集まっている…そうですね、他社にいたとしたらその会社で技術や組織を牽引できそうな人が普通に集まってきていると感じます。英語がスラスラと話せる人も珍しくありません。そんな中、自分がその中に加えていただけたことを感謝しています。

今後

組織として何をしていくかは常にメッセージが発せられており、それに準じて自分が何をなすべきかを考えて行動し、結果を出していくまでだなと考えています。ですので、組織の中で自分が何をするかについての迷いはあまりありません。

また、この先に進むには、技術者として必要な力をさらに鍛え、そして英語力(英語学習が推奨されており仕組みもある)を高める努力が必要になっています。自分自身のこれまでとは違った大変さがあります。さもなくば、先ほども書きましたが組織の中に自分が埋もれていってしまうかもしれません。

LINEで送る
Pocket

2015年を振り返る&退職のご報告

LINEで送る
Pocket

2015年を振り返るエントリです。毎年棚卸ししつつ書くことで、自分が何をやったかを思い出すものになっています。

対外的な活動

今年は大きく3つありました。

  1. 単著の出版
  2. YAPC::Asia Tokyo 2015でのトーク
  3. 都立産業技術高専での非常勤講師

1は、初の単著を出版する運びとなりました。「「ITインフラ監視実践入門」という本を書きました!」というエントリで詳細を書きました。こうして出せることでなんとかほっとしています。

2は、2年連続でYAPCでトークをすることができました。今年は倍率が高くてできるか心配だったのですが、ご縁があり採択していただくことができました。詳細は「YAPC::Asia Tokyo 2015で開発・運用業務改革に関する発表をしてきました&感想 #yapcasia #yapcasiaE」に書きました。

3は、2015年の後期から都立産業技術高等専門学校(高専)でプログラミングの科目を担当する非常勤講師をしています。これは情報教育関係でご縁があり、仕事を紹介してもらった次第です。ソフトウェア開発をするのではなく指導するという毛色の違った仕事ですが、明日の仲間を増やすきっかけになればと思いながら取り組んでいる次第です。

個人ブログ

はてなブックマーク数の表示が2つあるものがありますが、これは2015年10月からこのブログをHTTP/2に対応した際に発生したURIスキームの変更によるものです。前者がhttp、後者がhttpsでアクセスした時のブックマーク数となります。1つしかないものは、パッと見で分かりにくくてすいません、9月まではhttp、10月以降はhttpsと思っていただければ幸いです。

子供が生まれまして、昨年に比べて勉強会へ行けるタイミングがぐっと減ったため技術エントリも減っております。これは、状況が変わって力をを注ぐところを変えているんだな、と思っていただけたら嬉しいです。

状況が変わったことに関連して、「エンジニアとしての落としどころを作る」というエントリを書いたのですが、これが370ブックマークを超えていて、結構伸びたなという感想を持っています。生き方に悩んでいる方が一定数いるのでしょうね。私もその一人です。

会社のブログ

勤務先でもブログ「インフラエンジニアway – Powered by HEARTBEATS」を共同執筆者の一人として書いていました。以下は私が担当したものです。

今年は1月に書いたRundeckのエントリがよく読まれていたようです。ジョブスケジューラの選定は運用時の頭を悩ませる問題の一つであり、かつベストプラクティスがなかなか見つからないところにフィットしたのではと分析しています。

また、運用とは関係ありませんが、Golangに関する記事も読まれているようでして、Golang熱が高まっているのかなと感じる結果となりました。

退職のご報告

先のブログでもおなじみでした、本務として勤務していた株式会社ハートビーツを今年いっぱいで退職することとなりました。謹んで報告いたします。

これからはITインフラが盛り上がるぜ!と思って入社したものの、はじめの頃は肝心のITインフラの運用で大きくつまづいてしまい、多くの人に大変な迷惑をかけてしまいました。そんな中、残されたソフトウェア開発の力を使って、ITインフラを直接扱うエンジニアの仲間の土台を支えるソフトウェアを開発し、自動化・標準化を推進する立場となりました。その中で、初期の失敗を挽回したいという一心で、なんとか今年のYAPCでご報告するレベルにまで到達させることができました。

これも、粘り強い、そして優しい仲間に支えられた結果だと感謝しています。本当にお世話になりました。ありがとうございました。

まとめ

今年は1人目の子供も生まれ、ガラッと生活が変わりました。そのため、独身時代のように仕事中心ではなく、できるだけ多くの時間を家庭の時間として使うよう生活するように変わりました。それでも、思ったより自分は対外的な活動をしているなと感じました。

今ある人生は過去からの連続した変化からの結果で、それが未来に続くという認識は、昨年からは変わりません。しかし、人の生死に限って言うと、連続性がない大きな変化だと受け止めています。正直、どのようにやっていけば良いのか結構悩んだ年になりました。それでも、こうやって生きていけているので、なんとかなっているのかもしれません。

来年は本務の勤務先も変わりますので、また違った変化が起こることでしょう。いろいろなことがありそうですが、まずは淡々と受け止めて、冷静な判断と燃え続ける心をもって事に当たる所存です。

皆様、今年も一年、大変お世話になりました。良いお年をお迎えください。

LINEで送る
Pocket

「ITインフラ監視実践入門」という本を書きました!

LINEで送る
Pocket

このたび、「ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)」という本を執筆・刊行する運びとなりました。

2016/01/16より発売です!Amazonなどのオンライン書店では先行予約も始まっております。

ITインフラ監視実践入門 書影

電子書籍版もあります。「Gihyo Digital Publishing」のサイト、またはKindleをどうぞ。

こんな人にオススメ!

  1. サーバの監視設定ってどうやればいいかわからない
  2. サーバの監視設定はやったけど監視の業務をどう回せばいいかわからない
  3. サーバの監視についてまとまった情報が欲しい

本書では、体系的な知識を持ってすれば、多くの方にもサーバの監視設定を行っていただくことができるよう、まとめています。

現在、Webサービスをはじめとしたサーバを用いたシステムを運用するにあたって、サーバの監視は外せない業務となっています。しかし、サーバの構築やチューニングの情報に比べて、サーバの監視の設定や業務についての情報はあまり多くなく、苦労されている方も多いかと思います。また、サーバの監視は経験と勘を持つ人が強いということも、難しいという意識を高める要因になっているはずです。

本書が、そんな悩みを解決できる一助になれば、幸いです。

章構成

大まかな構成は、概要(1, 2章)→設計(3〜6章)→構築(7章)→運用(8, 9章)となっています。

1章は、監視の必要性についてお伝えしています。

2章は、この後の章で述べる監視設計についての流れについて説明します。システムを「5つのレイヤー」に分けて整理していくことで、何をどのように監視するのか整理しやすくする手法を紹介しています。

3章では、これから監視するシステムの現状分析方法について述べています。どのような情報が設計時に必要になるのか、網羅しました。

4章では、監視の設計で最も重要な監視閾値の定義の仕方についてお話ししします。3章の情報をもとに進めていきます。

5章では、監視サーバの設置についてまとめています。オンプレミス、SaaS、それぞれの利点と注意点に留意しながらどのように監視サーバを設置すると良いのかをまとめています。

6章では、監視業務をいかに回すかを説明します。障害発生時の意思決定の流れ、そして休日・夜間にどのように監視を継続していけば良いのかを確認します。

7章では、MackerelとUptime Robotを用いて監視システムを構築する方法をご紹介します。実際に手を動かして監視設定を行ってみてください。

8章では、障害対応をはじめとした日々の運用の回し方について述べています。障害をいかに迅速かつ丁寧に対応するのかのノウハウをお伝えします。

9章では、自動化を見据えた監視システムの設計のコツについてお話しします。

執筆のきっかけ

以前、YAPC::Asia 2014でサーバ監視設定に関するトーク(「YAPC::Asia 2014 に参加してトークして飲み切ったら夏が終わった #yapcasia」を参照)をしたことがありました。その場では、会場を埋め尽くすほどの多くの方に関心を寄せていただきました。

そこで、トークではお話ししきれなかったことを本として改めて網羅し直すことで、より深く、そしてより多くの方にサーバの監視設定についての知見をお伝えできたらと思い、執筆することになりました。

ぜひお買い求めください!

そして、感想をブログに書いていただいて、Twitterなどでシェアしていただけたら嬉しいです!確認し次第、読むようにします。

LINEで送る
Pocket

TENTO 第4回プレゼン大会の幹事をしてきました

LINEで送る
Pocket

少し遅くなりましたが、10月25日(日)、僕が小学生〜高校生にプログラミングを教えるボランティアをしているTENTOにて、毎年恒例のプレゼン大会の幹事をしてきました。今回は4回目、東海大学さんのキャンパスをお借りして催すことができました。

プレゼン大会について簡単に説明すると、TENTOは小学生〜高校生にプログラミングを指導する私塾でして、様々な年齢の生徒さんが自分のレベルにあわせて様々なソフトウェア開発を学びます。言語も様々、ペースも様々で、現代の寺子屋といっても過言ではありません。

当日の模様をブログにまとめている方がいらっしゃいましたのでまとめてみました。

また、以前のプレゼン大会の模様は次のエントリにまとめています。

IMG_3752

さて、今回のお話は、「発表に賞はつけない」「実際に作品に触れることの良さ」そして「イベントのネットワークについて」の3点についてお話しします。

発表に賞はつけない

今回、発表では3つの部門(「Viscuit+Scratch高学年」「Scratch低学年」「テキストプログラミング」)を用意しました。これまでは審査員の方がそれぞれの部門のトップ賞を決めていたのですが、今回は止めました。そのかわり、審査員はスーパーバイザーとして、発表後に発表者した子全員に対して30秒程度の講評をお話し頂くことにしました。

なぜこうしたかというと、3つの理由があります。

  1. 一人一人、年齢と成熟度が違うから。
  2. プログラミングの良さを決めることは簡単な話ではないから。
  3. 何を糧にして明日プログラミングに取り組めば良いかプロからのコメントを送って欲しいから。

1は、年齢が高くなればなるほど、人として知識や知恵がつく傾向にあります。従って、「小学1年生」とよほど細かく単位を区切らない限り、上級生の方が良い作品を作りやすい傾向が出てしまい、審査に公平感が出なくなります。また、細かく切ることができるほどには生徒は増えていません。

2は、例えば競技プログラミングなどの明確な基準があれば賞を出すことはやぶさかではありません。しかし、TENTOのプレゼン大会で出てくる作品は、テーマの縛りがない状態で、生徒さん一人一人が最も自信があり、最良だと考えて開発した作品が出てきます。従って、一定の基準を設けて審査することは容易ではありません。言い換えれば、一人一人が最高の作品を作ってきているのです。

3は、1と2を受けてのことでした。今、前線でソフトウェアと向き合っている人たちからの温かい言葉を受けて、生徒さん一人一人の自信につなげて欲しいと願い選択しました。担当は、OtOMO 代表の倉本さん、株式会社ワディット代表で @yusukebe こと和田さん、そしてピープルウェア翻訳者で東海大学の山浦先生にお願いしました。

イベントと言うとついつい賞を出すと自然と考えてしまいがちですが、そうではない形があるということを、日本のプログラミング教育のパイオニアを自負しているTENTOから発信できたとしたら、幸いです。

実際に作品に触れることの良さ

今回、発表は1トラックだったため、急増する生徒さん全てを発表のステージに立ってもらうことは叶わない状況となってしまいました。そこで、発表する人も、そうでない人も、作品を展示できる機会を設けました。これは昨年試行して好評だったため、今回からイベントの中に正式に組み込むことにしました。

IMG_3788

TENTO代表の竹林さんは「プレゼン大会を学園祭のようにしたい」という想いがありました。また、全ての発表したい生徒さんに何らかの機会を提供することは、指導を担当する私たちの責任でもあると考えていました。その結果として、展示が存在しています。

展示の良い所は、生徒さん同士で交流が発生することです。これは情報交換を通じて互いのプログラミングスキル向上が期待できることはもちろん、「これは良い作品を作っているな!」と互いが喚起しあうことでモティベーションを高める効果もあります。また、あちこちに人が行き交うため、まさに学園祭のような様相を呈します。なかなかよいものですよ。

この展示イベントだけでももう少し短期間でやってもいいかな、そう思えるくらいです。

イベントのネットワークについて

せっかくですので、ネットワーク環境について述べておきます。

ネットワークは、公衆回線はUQ WiMAXのURoad-Home2+ → ルーターはYAMAHA RTX810 → Wi-FiはYAMAHA WLX302 で組んでいます。PCは40台以上接続しています。この状態で、ノントラブルで乗り切ることができました。

ScratchやViscuitはhttpの非同期通信が多発しますので、ルーターにNATテーブルを多量に要求するなかなかシビアな環境です。また、家庭用Wi-Fi機器ではさすがにこのPCの台数を支えることはできません。一方で、アクセスポイントを増やすだけですとかえって通信が輻輳しますので、よほど慣れていない限り避けた方が良いです。

これらのコツは、Software Design 2015年3月号の「カンファレンスネットワークの作り方」で解説されていますので、検討される方や、実際にネットワーク環境に困っている方はぜひ参考にしてみてください。

一つのフォーマットの完成

TENTOのプレゼン大会を第1回から手伝ってきまして、4回まで来ますとだいたいのイベントのフォーマットができたかなと思っております。発表と展示、相互に盛り上げることで生徒さんのプログラミングスキル向上の一つのマイルストーンにできているのではと自負しています。また、TENTOという場で、コンピュータとは何か、そしてそれを通じて仲間の絆や、学校で学びづらいスキル(プレゼンテーションや論理的思考力)を生徒さんが理解してもらえたら何よりです。

実は、私は家庭の事情から、このイベントを持ってTENTOを離れることとなりました。その一区切りに、TENTOで一番はじめに取り組んだプレゼン大会で締めることができることを幸運に思います。大変感謝します。

また、ここまでに至るまでに、代表の竹林さんをはじめ、多くの仲間に支えられてここまでできたことを深く感謝しています。重ねて、どうもありがとうございます。

IMG_3819

情報教育自体には引き続き関心を持ちながら生活して行きますので、イベント等でお会いする機会がありましたら、どうぞよろしくお願いします。

LINEで送る
Pocket