佐野裕のレビュー一覧
-
Posted by ブクログ
良書。インフラエンジニアの仕事内容からサーバ、OS、ネットワーク、ストレージ、サーバ仮想化、クラウド、購買・商談、データセンターまで、正にインフラエンジニアとして知っておくべき内容が網羅されている。OS、ネットワーク、ストレージなどは基本情報技術者試験で学んだ内容の復習となった。購買・商談やデータセンターについては普段の業務では触れることが無いため自分にとっては新鮮な内容であった。実務者が執筆した書籍だからこそ言葉に中身があり、どんどん読み進めることが出来た。続編も読みたい。
想定読者として現役インフラエンジニアだけでなく、これからインフラエンジニアになりたい人も書かれているが、資格無し実務経験無しだと難しく感じられる箇所もありそう。 -
Posted by ブクログ
単に3つのクラウドベンダの機能を比較するだけかと思っていたが、想像以上に読みやすく分かりやすく、学びとしてとても良かった。
クラウドの基礎知識から、AWSを中心に具体的な使い方(手順)も適宜紹介していて「教科書」の何恥じぬ一冊。クラウドエンジニアの目指す方向性、や資格の一覧などもある点からベンダ紹介に留まらないことが伺えて好印象。
AWS、GCP、Azureそれぞれに用語や癖や出来ることの多少の差異はあるものの、基本的なつくりや実現可能なことはほぼ一致しているので、具体的にどのような用途で使うかや、どのようなレガシー資産があるかによって選ぶ形となるだろう。
金銭的にどれが優位か、というのははっきりとは選べない。というのは、金額体系がことなるからと、使う用途によって計算方法が全然変わってくるからである。
そういうわけでも、どれを選んだらよいかというベストアンサーは「使う人による」であって、クラウドエンジニアとしてはこの辺のインフラ導入の要件定義~基本設計が出来るスキル・知見が要となってくるだろう。
個人的には特にチャプター09のInfrastracture as Code(IaC)部分がとても有益だった。
IaCに関してはまだ全く触れたことがなかったので新規の知識だったが、かなり理解できた。
本書内では「手動とInfrastracture as Codeでのインフラ構成管理の違い」と銘打って比較解説がなされているが、手動でのインフラ構成管理=ドキュメントによる管理、となっているため確かに差は明白だろう。
自分は構成管理としてChefを2年弱やった経験があるのでIaCの仕組みにはこういった構成管理ツールに非常に近しいものを感じた。バージョン管理がGitなどのVCSと連携して使用可能な点が非常に魅力的。Terraformぜひ使ってみたい。
Ansibleはまだ使ったことないが、Gitとの連携とかあるのだろうか。別途調べてみる。 -
Posted by ブクログ
相変わらず幅広くそつなくおさえられている。OSの章のプロセスとスレッド、メモリ、ファイル管理のあたりが特にためになった。ゴリゴリに技術的な話から海外のエンジニアとのコミュニケーションで気を付けること、といった話まで展開されるのが少し笑えた。
・プロトコル
・OS
・ネットワーク
・データベース
・WEBのサーバサイド開発言語
・共通鍵暗号方式と公開鍵暗号方式
・障害対策と障害対応
・よく知られたセキュリティ攻撃
・インターネットの運用と発展をつかさどる組織や団体
・RFCの読み方と作られ方
・世界規模のインターネットサービス運営
・インフラエンジニアとして目指す方向 -
Posted by ブクログ
ネタバレインフラエンジニアという仕事への入口
本書は、インフラ技術を深く掘り下げる技術書というより、IT業界を目指す人に「インフラエンジニアという仕事は何なのか」を理解してもらうための地図だと感じた。「用語がわかる!」「概念をつかむ!」「挫折をしない!」という表紙の言葉も、その位置づけで読むと腑に落ちる。特に、インフラエンジニアになったきっかけを四人の経験から紹介する章は、最初から明確な志望を持っていなくても、この職種にたどり着くことがあるという現実的なキャリア像を示している。
自分はインフラエンジニアだったのか
面白かったのは、本書を読んでいるうちに、自分自身のキャリアを別の角度から見直すことになったことだ。私は1992年に社会人になり、当時からEthernetやIP、Internet、Web、ネットワーク管理などに触れてきた。ただ、自分を「インフラエンジニア」と考えたことはなかった。むしろ会社に入った頃には、運用保守だけは絶対に担当したくないと公言していた。それでも本書の職種説明と自分の経験を照合すると、専門分野のすべてを知っているわけではないものの、自分も長い間、インフラという問題領域の中で仕事をしてきたのだと気づかされた。
技術は変わっても問題は変わらない
1990年代から現在までを振り返ると、CMIPからSNMP、X.400からRFC 822系のメール、ATMからEthernet+IP+TCP、X.500からLDAP、そしてSGMLからXML、JSONへと、複雑な仕組みがより実装・運用しやすい仕組みに置き換えられてきた。現在はクラウドやAIが加わり、技術はさらに巨大化している。しかし、ITで繰り返し現れる「つながらない」「遅い」「落ちる」「原因がわからない」「どう復旧するか」といった問題の骨格は、それほど変わっていないように思う。
結果から原因を逆算する
だから、ITを学ぶときに重要なのは、現在存在する技術を覚えるだけではない。その技術が「何の問題を解くために生まれたのか」を考えることだと思う。現在は結果として存在する技術が並んでいるため、なぜそこに至ったのかが見えにくい。目の前の結果から、どのような原因や制約があったのかを逆算する。これはシャーロック・ホームズ的な「逆説的に考える」姿勢であり、インフラのトラブルシューティングにも通じる。
詰将棋としてのインフラ
インフラの仕事には、制約の中で次の一手を考える、詰将棋のような面白さがある。定石を知り、状況に応じて使い分け、定石が通用しなければ別の手を考える。さらに熟練すると、問題を解くだけではなく、監視や手順、構成を設計して、そもそも難しい局面が発生しにくい「問題そのものを解きやすくする」ことまで考えるようになる。これは、パズルを解く能力から、パズルを作る能力への発展ともいえる。
本書を読んで見えてきたもの
本書は、その意味では「インフラエンジニアになるための最初の一冊」であると同時に、読者自身が自分の適性を考えるための一冊でもあると思う。私自身は本書の想定する初学者ではない。それでも、本書をきっかけに、自分はインフラエンジニアではないと思っていたが、実はインフラの設計、構築、運用、保守という世界を長く経験してきたことに気づいた。そして、避けたかったはずの運用保守をよく知っていることが、現在、仕組みや問題を構造的に捉えるコンサルタントとしての自分を支えているのかもしれない。
技術の名前が変わっても、問題を見つけ、原因を考え、制約の中で一手を選ぶという営みは残る。本書を入口として、その先にあるこの面白さまで見えてくると、インフラエンジニアという仕事は、また違った姿を見せてくれる。 -
Posted by ブクログ
最近勉強して多少は詳しくなったつもりであったが、本書は全く歯が立たない内容だった。やはり机上で勉強するのと、現場で必要な知識には相当に差があるということか。
・RDBMSの選定理由
?Oracle Database
・ミッションクリティカルな場面での導入実績が豊富。特に課金系や認証系など、さまざまな基幹系でよく選定される。
・大規模環境向けの機能が豊富である。
・早くから可用性を高める機能が実装されていた。エンタープライズサーバ+UNIXの環境で用いたい。
?SQL Server
・Microsoft.Net環境でアプリケーションを構築しているので同じMicrosoft製品として親和性が高い。
・商用RDBMSを使いたいがOracle Databaseは高価。
・最新のハードウェアと組み合わせて高性能を求める。
・普段、Windowsしか使っていないユーザが、Accessなどの延長上に選定する。
?MySQL
・無料で使いたい。
・WEBサービスで利用実績が豊富で、ネット上に様々な情報が掲載されている。
・MySQLに接続が容易な開発言語でアプリケーションを開発している。
・障害発生時にはソースコードまで見て原因分析をしたい。
?PostgreSQL
・商用RDBMSを使っていたが、オープンソースに置き換えたい。特にOracle DatabaseからPostgreSQLへ置き換える事例が多い。
・PostgreSQLに接続が容易な開発言語でアプリケーションを開発している。
・WEBサービスで利用実績が豊富で、ネット上に様々な情報が掲載されている。
・障害発生時にはソースコードまで見て原因分析をしたい。
・リストアとリカバリ
リストアはバックアップファイルを復元すること。リカバリはWALログを適用してデータベースを障害発生直前の状態にすること。