はてなの金次郎

とあるエンジニアの技術系ブログ

「3 分間ネットワーク基礎講座」から学んだこと。

3分間 ネットワーク 基礎講座

3分間 ネットワーク 基礎講座

概要

  • 著作: 「3 分間ネットワーク基礎講座」
  • 著者: 網野 衛二
  • 著者経歴:文系大学卒業後、紆余曲折してコンピューター系の専門学校の講師として、ネットワークの構築・管理・授業を行っている

目的

ネットワークの雰囲気理解を脱する

要約

ネットワークはコンピュータ間でのリソースの共有のために行うデータ通信のことで、OSI 参照モデルという標準規格を ISO が制定した。実際には IEMF が提唱した TCP/IP モデルがデファクトスタンダードとして利用されている。OSI 参照モデルも TCP/IP モデルもデータ通信を独立したレイヤーに分け、それぞれプロトコルを定めることで役割を明確化している

感想

先生と生徒の会話形式で説明が進んでいくことで少しずつ疑問が解消でき、一歩ずつ前に進めた。低レイヤーの知識はアウトプットも難しく定着しにくいので、ちゃんと復習したい。あと紹介されていた Wireshark を使って実際のデータの流れをみてみる。

次のアクション

Wireshark 触ってみる

「スターティングGo言語」から学んだこと。

スターティングGo言語

スターティングGo言語

概要

  • 著作: 「スターティング Go 言語」
  • 著者: 松尾愛賀
  • 著者経歴:株式会社ラクーンの技術戦略部のエンジニア。主に新事業系の技術基盤などを担当

目的

Golang のセマンティックを知る

要約

Go はシンプルかつ高速なプログラミング言語で、開発者が最小の手間で実用的なプログラミングを実装できるように設計されている。これらは gorutine という I/O をベースにした効率的な並列処理や、ネイティブなバイナリ出力といった Go の特徴的な機能に現れている。

感想

Golang 初学者向けに書かれた良書。A Tour of Go ではわからなかった Golang の細かいセマンティックを知れた。また、オブジェクト指向ではない・マルチプラットフォーム・厳格なコンパイラなどといった他のメジャーな言語との違いについて触れられており、Golang の特徴をより深く理解できた。標準パッケージが非常にわかりやすくまとめてあり、辞書的に使うこともできそう。ただ、バージョンが 1.6 で少し古いので最新の情報などは別途補完したい。

次のアクション

最新の情報を補填したり、習慣的に Go の情報をキャッチアップする。以下がよさそう。

「Effective DevOps」から学んだこと。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

概要

  • 著作: 「Effective DevOps」
  • 著者: Jennifer Davis, Ryn Daniel
  • 著者経歴:
    • Jennifer Davis:DevOpsDays の世界的なオーガナイザー。
    • Ryn Daniel:モニタリング、構成管理、運用ツールの開発のスペシャリスト。

目的

DevOps とはどのような活動なのか知る。devops エンジニアとしてのキャリアを考察する。

要約

devops はあらゆる職種を超えて組織や個人が継続的かつ効率的に学習し続けるようにするプロセスのこと。コラボレーション、アフィニティ、ツール、スケーリングの 4 本柱を考慮することで効率的な devops を実現できる。

感想

devops はかなり抽象的な概念であることがわかった。書籍の中で何度も説明される言葉に幅があったからだ。

devops は文化運動であり、思考の方法であり、仕事の方法であり、文化的なフレームワークであると。

抽象的な説明であっても何度も何度も繰り返されればなんとなく理解できるということがこの本を読んでわかった。devops の説明の中で毎回と言っていいほど出てきた単語が「組織」と「学習」だった。あらゆる職種を超えて組織や個人が継続的かつ効率的に学習し続けるようにすることが devops が目指すものらしい。そう言われてみると、devops だけが目指しているゴールではなさそうである。スクラム、リーン、バージョン管理、コンテナ、CI/CD など、ソフトウェア工学の歴史の中で数々の人や組織が紆余曲折しながら得た知の結晶が devops であるとも言えるのではないかと本書を読んで感じた。

本書を読む前の自分の devops のイメージは自動化とか、効率化とかそんな漠然としたイメージでどんなアプローチで自動化すればよいのかなどの答えを求めて読み始めたが、読んでいる途中で、Team Geek やエンジニアリング組織論への招待に近い本だと思った。よりよいプロダクトを作るためのよりよいチーム作りのヒントが詰まっていた。あまり注目していなかったが、サブタイトル「持続可能な組織文化の育て方」の方がしっくりくる。

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

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

そして、言葉を変えながら何度も繰り返されていたのは devops を実践するための唯一無二の正しい方法は存在しない、誰もが使える「devops をやる」方法はないということである。

ここで devops エンジニアというキャリアを考察してみると、やりがいがある一方でかなり難しい職種であると感じた。なぜなら、devops は考え方であり、仕事の進め方である。さらに、正解があるわけではない。組織によって実現方法は様々で、あるツールを導入すればよいわけではなく、数あるツールの中からその組織フェーズにあったツールを選定し組み合わせワークさせることができてはじめて devops といえる。相当の知識量と組織を導く推進力が必要な職種である。実際、本書では devops エンジニアという肩書きに関して以下のことが言及されている。

devops エンジニアという概念は全く非現実的であり、スケーラビリティもない。


企業が成長して成熟してくれば、社員には専門分化した肩書きを与えた方が合理的だ。


ひとりの社員に 2 つのフルタイムの職務を期待するのは、燃え尽きてくれというのと同じことだ。

なんでも一人でこなせるのは理想とするエンジニア像のひとつだが、devops エンジニアという肩書きでなくても devops に関われる形があることがわかった。組織論やカイゼン活動は好きなので関われる形を模索していきたい。

次のアクション

実際どのように業務に落とし込めばいいのかまではこの本では少し抽象的すぎてわからなかった。開発者としてできるもう少し具体的な devops の実践方法を知りたい。少し調べてみたところ、SRE 本がよさそう。SRE 本の中では devops との違いについて、class SRE implements DevOps と説明されているらしい。まさに求めている内容ではないか!