Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
Search
Tadahiro Ishisaka
May 05, 2023
Technology
0
63
インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を知らなければならないわけ
プログラマが仮想レイヤーであるインフラを知らないことによる悲劇と、そこをどうしていこうかと言う話。
まぁ古い話ではある。
Tadahiro Ishisaka
May 05, 2023
Tweet
Share
More Decks by Tadahiro Ishisaka
See All by Tadahiro Ishisaka
開発から見たWindowsの国際化機能
ishisaka
0
170
Other Decks in Technology
See All in Technology
コンパウンド組織のCRE #cre_meetup
layerx
PRO
1
290
JAWS UG AI/ML #32 Amazon BedrockモデルのライフサイクルとEOL対応/How Amazon Bedrock Model Lifecycle Works
quiver
1
120
激動の時代を爆速リチーミングで乗り越えろ
sansantech
PRO
1
180
東京大学「Agile-X」のFPGA AIデザインハッカソンを制したソニーのAI最適化
sony
0
160
AI駆動で進める依存ライブラリ更新 ─ Vue プロジェクトの品質向上と開発スピード改善の実践録
sayn0
1
340
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.4k
SRE × マネジメントレイヤーが挑戦した組織・会社のオブザーバビリティ改革 ― ビジネス価値と信頼性を両立するリアルな挑戦
coconala_engineer
0
300
QA業務を変える(!?)AIを併用した不具合分析の実践
ma2ri
0
160
オブザーバビリティと育てた ID管理・認証認可基盤の歩み / The Journey of an ID Management, Authentication, and Authorization Platform Nurtured with Observability
kaminashi
2
1.3k
OPENLOGI Company Profile for engineer
hr01
1
46k
CNCFの視点で捉えるPlatform Engineering - 最新動向と展望 / Platform Engineering from the CNCF Perspective
hhiroshell
0
150
.NET 10のBlazorの期待の新機能
htkym
0
160
Featured
See All Featured
Six Lessons from altMBA
skipperchong
29
4k
Building a Modern Day E-commerce SEO Strategy
aleyda
44
7.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
54k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
How GitHub (no longer) Works
holman
315
140k
Stop Working from a Prison Cell
hatefulcrawdad
272
21k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
Transcript
第6回静岡ITPro勉強会インフラ部 インストール100回だ(゚Д゚)ゴルァ!! プログラマがインフラ技術を 知らなければならないわけ
プログラマに インフラ技術が必要なわけ
えーマジ インフラ知らない!? キモーイ インフラを知らないのが許され るのはコーダーまでだよね! キャハハハハハハ
Fact 1 • ネットワーク切断が考慮されていない ネットワーク分散システム – クライアントが数分固まってエラー – RPCを使っているのに相手がいないことを前 提としない(DCOM)
– このため、障害時の調査やデバッグが当て外 れで復旧に多大な時間がかかる。(ハブのス テータス見れば一瞬だった) • 本質的なエラー原因はハブの故障 – 最終的にユーザーは別の会社に修正を依頼し た。
Fact1の本質的な原因 • DCOMという分散オブジェクトを利用してい るが、クライアントプログラムを作ったプロ グラマがC/Sを理解できていなかった。 – ローカルでの開発・デバッグ – フレームワークの仕組みについての無知 –
テストの不足だが、そもそもこれではテスト項目 として洗い出しできない – エラーメッセージもユーザーに対して適切に提供 できていない • DCOMのHRESULTがそのままメッセージボックスに。
Fact2 • クライアントからの呼び出しに応じて RDBMS上のデータを読み書きするサービ スがあったが、ある日RDBMSのサーバー を統合化したのだが、それ以後システム が動作しない。 – シスアドがRDBMS接続の設定ファイルを探し たが見つからず、変更でいない
– 仕様書を確認したが起動パラメーター等もな し
Fact2の本質的原因 • プログラマがRDBMSをそもそもわかって なかった。 – サーバーというものが移動されるという前提 が共有できていない • このため接続設定を変更可能にするという発想が 無かった。
– プログラマがそもそもフレームワークとツー ル任せで接続設定等について理解ができてい ない。 – プログラムの修正が必要になった
Fact3 • 試験環境では正しく動作し、レスポンスも十 分だたしステムが、実行環境に移したら、シ ステムのターンアラウンドに数分もかかって しまい使い物にならない。 – セッションごとにRDBMSが動作するサーバーの負 荷率が数分間100%になる –
ついでにストレージサーバーの負荷率も急上昇 – ストレージサーバーを共有する他システムに影響 が出始める – ユーザーが結局RDBMSチューニングのスペシャリ ストをお願いし、適切なチューニングをして今日 できる範囲にターンアラウンド時間を改善した。
Fact3の事実 • プログラマがSQL言語への知識が薄く、経験 もほぼ無かった • ORMフレームワークを使用し、SQLのクエ リーはノーチューン、テーブルもORM任せで インデックス処理等もされていなかった – 毎回全テーブルスキャンするので遅いのは当たり
前。 • プログラマに大規模なデータになったときに 何が必要か想像できれば事前に何とかできた はず。
プログラマがインフラを知らない と何が起きるのか • 設計の不足 – 非機能要件に対する設計不足 • 障害やパフォーマンスに対する設計 • テストの不足
– 非機能要件に対すテスト不足 • 障害やパフォーマンスに対する試験 • 結果として不完全なソフトウェアシステ ム
ソフトウェアと ソフトウェアシステム • ソフトウェアシステム – 複数のソフトウェアが相互連携して動くのが ソフトウェアシステム – 一つのプログラムでは完結できない •
すべて自分だけですまない • 相手はいないかもしれない • 相手に負荷をかければうまくシステムとして動か ない • 相手との距離感を理解できているか。
自称プログラマの現実 • OSのネットワーク設定ができない • OSのインストールができない、したこと 無い。 • ネットワークとか知らない。(のに自称 WEB系プログラマ。PHPは何となくかける らしい)
• RDBMSってなに?おいしいの? • 配線ができない
そもそもどうやって 自分の書いたコードが 動いているかわかってね-
想像力を持つためのインフラ知識 • 以上の問題は究極的にはプログラマがソ フトウェアシステムに対してどれだけの 想像力を持ち得るのかという問題 • 想像力は山勘では無い – 知識が無いことは想像できない –
経験が無いことは想像できない • プログラマが失敗しない(させない)ために はインフラ知識と経験が必要
プログラマにどのように インフラ技術を教えるか
目的をしっかり持つ • 目的はインフラエンジニアになることで は無い • ソフトウェアシステムの設計・構築を可 能にするための知見を持たせるのが目的 – 深掘りさせすぎてもいけない –
できるだけまんべんなく
ビルド環境の構築と管理 • ビルド環境を構築させる – OSのインストール – ネットワーク環境の設定 – 開発環境のインストール –
ユーザー設定 • ビルド環境のお守り – ユーザー管理 – バックアップ – 設定変更 • 単独サーバーの構築と管理を学ぶ
テスト環境の構築 • 複数のサーバ・クライアントからなるシ ステムの構築と運用 • ネットワークの物理的な接続、SWハブや ルーターの設定等も段階を踏んでやらせ る。 • 場合によっては理論的なところの講義と
かも必要。
丁稚 • OJT – で済まさない – 論理的な点をどこまで教え込むか – やってみせる –
やらせてみる – 背中を見せる • 先輩の姿勢が後輩の姿勢 • 丁稚に出す – 社内に管理部門やサービス部門があれば 帰ってくる約束で配転してみる。
数をこなすことで わかることもある インスコ100回だ ( ゚Д゚)ゴルァ!
経験は積まないといけない • 本だけでは駄目 • 体で覚えることも必要 • 数をこなすことで見えてくることもある • 少ない機会の中でいかにインフラ的経験 を積ませるかが吉
本人と教える側のツール • ITスキル標準 – 目指すはITアーキテクト – 何を目指すのかの目標設定 http://www.ipa.go.jp/jinzai/itss/index.html
IT技術者を目指す • そもそもプログラマと管理者の違いなん て元々無かった • システムが大規模になったので分業化し た • 両方に目を配れるIT技術者を目指そう
*宣伝* • 2/18(土) Windows Azureの勉強会やります! • 第1回JAZUG静岡勉強会/第8回静岡ITPro勉強会 – 場所:静岡県立大 –
http://www.zusaar.com/event/199062
No Code, No Life.