11/11 DevOpsハンドブック読了
アウトプット項目
DevOpsハンドブック 学習
- Push on Green
- Testing on the Toilet
- コードと環境を継続的にビルド、テスト、インテグレートする
- 高速で信頼性の高い自動確認テストスイート
- デプロイパイプラインが壊れたときはアンドンの紐を引く
- 小さなバッチによる開発についてとトランクへのコードコミットが頻繁に行われない場合に何が起着るかについて
- トランクベースの開発という実践手法
- デプロイプロセスの自動化
- リリースからデプロイを切り離す
- 生産性、テスト可読性、安全性を実現するアーキテクチャ
- アーキテクチャの原型: モノリシックとマイクロサービス
- 絞め殺しアプリケーションパターンを使って安全に前者のアーキテクチャを発展させる
- 一元的な遠隔測定インフラストラクチャの作り方
- 本番システムの運用を助けるためにアプリケーションにログ作成機能を追加する
- 問題解決の道案内として遠隔測定データを利用する
- 日常業務の一部として指標を生み出せるようにする
- 遠隔測定データと情報ラジエーターにセルフサービスでアクセスできるようにする
- 遠隔測定の穴を埋める
- 平均と標準偏差を使って問題となり得るものを検出する
- 望ましくない結果を測定してアラートを送る
- 遠隔測定データが正規分布に従っていないときの問題
- 異常値検出テクニックの使い方
- 遠隔測定データを使ってデプロイをより安全なものにする
- 開発と運用でオンコールを共有する
- デベロッパーに下流の仕事を観察させる
- 最初の段階では本番サービスをデベロッパーに管理させる
- A/Bテスト
- 機能テストにA/Bテストを組み込む
- リリースにA/Bテストを組み込む
- 機能のプランニングにA/Bテストを組み込む
- 変更承認プロセスの危険性
- 「過度に管理された変更」が秘める危険
- 変更の調整と日程管理の実現
- ピアレビューの実現
- マニュアルテストを増やして変更の凍結期間を延ばすことの危険性
- 変更の品質を上げるためにペアプログラミングを実現する
- プルリクエストプロセスの有効性の評価方法
- 官僚主義的なプロセスを大胆に取り除く
- 公正なラーニングカルチャーを確立する
- 事故が起きたあとに非難なしのポストモーテムを開く
- できる限り広い範囲にポストモーテムを公表する
- 従来よりも弱い失敗の兆候を見つけるためにインシデントの境界線を引き下げる
- 失敗の意味を捉え直して計算されたリスクテイクを奨励する
- 回復力と学習を生み出すために本番環境にエラーを注入する
- エラーのリハーサルの為に試合日を設ける
- チャットルームとチャットボットで組織的な知識を自動的にキャッチする
- 標準化されたプロセスを再利用のためにソフトウェアにまとめて自動化する
- 組織全体で1つの共有ソースコードリポジトリを作る
- ドキュメントとしての自動テストとコミュニティを使って知識を拡散する
- 非機能要件を体系化して運用にやさしい設計を実現する
- 再利用可能な運用ユーザーストーリーを開発に組み込む
- 組織の目標を達成するために役立つ技術を選ぶ
- 技術的負債を返済するための儀式を制度化する
- 全員が教え、学べるようにする
- DevOpsカンファレンスで自分の経験を共有する
- 実践を広めるために社内コンサルティングとコーチングの組織を作る
- 開発イテレーションのデモに情報セキュリティを組み込む
- 欠陥の追跡とポストモーテムに情報セキュリティを組み込む
- 共有ソースコードリポジトリと共有サービスにセキュリティリスク予防ツールを組み込む
- デプロイパイプラインにセキュリティを統合する
- アプリケーションのセキュリティを確保する
- 遠隔測定に情報セキュリティを統合する
- アプリケーションのなかにセキュリティ遠隔測定を作り込む
- 環境のなかにセキュリティを遠隔測定を作り込む
- デプロイパイプラインを防御する
- 変更承認プロセスにセキュリティとコンプライアンスを組み込む
- 比較的リスクが低い変更を標準変更に分類し直す
- 変更が通常の変更に分類されたときに何をすべきか
- 職務の分離に対する依存度を下げる
- 監査人とコンプライアンス責任者のためのドキュメントと証拠を残す
参考
Todo
- AM
- DevOps Chapter 20
- DevOps Chapter 21
- PM
- DevOps Chapter 22
- DevOps Chapter 23
- ブログ執筆
結果
- AM
DevOps Chapter 20DevOps Chapter 21- PM
DevOps Chapter 22DevOps Chapter 23ブログ執筆
良かったところ
- DevOpsHnadbook終わらせた、、、
→継続する、イメージしながら読んでいく、インプットしたら必ずアウトプット
改善点
- 偏頭痛で9時間勉強することができなかった
→ゆっくり長く寝て明日したまた頑張る!!!
ルーティン
- 8:00起床~9:00準備
- ~10:00移動
- 10:00学習室にて学習開始
- 10:30 Todoリスト作成
- 10:30~ Todoに取り組む
- 14:00~14:30昼食
- 14:30~ Todoに取り組む
- 21:15~ 食事
- 21:45~ブログ執筆
- 22:00~ 移動
- 24:30就寝
11/7 DevOpsハンドブックアウトプット
アウトプット項目
DevOpsハンドブック 学習
- SLA
- ITIL
- ITSM
- アウテージ
- ダークローンチテクニック
- イテレーション
- スルートップ
- バリューストリームについて
- リードタイムとプロセスタイム
- デプロイリードタイム
- 数分単位のデプロイリードタイム
- %C/A
- DevOpsの原則 3つの道
- フローの原則
- 作業の可視化
- WIP(仕掛り)の制限
- バッチサイズの縮小
- 受け渡し数の削減
- 絶えず制約条件を見つけ出して尊重する
- バリューストリームからムダと苦痛を取り除く
- 複雑なシステムにおける安全な作業
- 発生と同時に問題を知る
- 新しい知識を作り上げるために組織が一丸となって問題解決に当たる
- 上流での品質確保を追求する
- 下流のワークセンターのために最適な出力
- 組織的な学習と安全尊重の文化を生み出す
- 日常業務の改善を制度化する
- ローカルな発見をグローバルな改善に転化する
- 日常業務に回復力を鍛えるパターンを注入する
- アンチフラジャイル
- リーダーが学習する文化を奨励する
- グリーンフィールドサービスとブラウンフィールドサービス
- バイモーダルIT
- SoR
- SoE
- 記録システムと参加システムの両方を考慮に入れる
- もっとも関心を持ちイノベーティブなグループから始める
- DevOpsの組織全体への展開
- バリューストリームを支えるチームを明らかにする
- バリューストリームマップを作成して作業を可視化する
- 専任の変革チームを編成する
- 共通の目標
- 改善の計画期間を短く保つ
- 非機能要件の強化と技術的夫妻の削減のために20%のサイクルを残せ
- 仕事の可視性を高める
- 組織の原型
- 過度に職能指向(コストのために最適化)になったときによく起きる問題
- 市場指向(スピードのために最適化)のチームの実現
- 職能指向の組織を機能させる方法
- 全員日常業務としてのテスト
- すべてのチームメンバーがジェネラリストになれるようにする
- プロジェクトではなく、サービスと製品に投資する
- Conwayの法則に従ってチームの境界線を引く
- 疎結合なアーキテクチャによりデベロッパーの生産性と安全を向上させる
- デベロッパーの生産性を上げるために共有サービスを作る
- サービスチームに運用エンジニアを配置する
- 運用のなかで個々のサービスチームに対する連絡担当を指名する
- 開発の儀式に運用を参加させる
- 開発のスタンド・アップに運用を参加させる
- 開発のレトロスペクティブに運用を参加させる
- 共有カンバンボードで関連する運用の仕事を可視化する
- イミュータブルインフラストラクチャ
- 開発、テスト、本番環境をオンデマンドで作成できるようにする
- システム全体で唯一の真正なリポジトリを作る
- 修理するよりも再構築する方が簡単なインフラストラクチャを作る
- 本番に近い環境で動作することの確認も含めて「完成」と言うように開発の「完成」の定義を変える
参考
Todo
- AM
- DevOps Chapter 0
- DevOps Chapter 1-1
- DevOps Chapter 1-2
- DevOps Chapter 1-3
- DevOps Chapter 1-4
- PM
- DevOps Chapter 2-5
- DevOps Chapter 2-6
- DevOps Chapter 2-7
- DevOps Chapter 2-8
- DevOps Chapter 3-9
- ブログ執筆
結果
- AM
DevOps Chapter 0DevOps Chapter 1-1DevOps Chapter 1-2DevOps Chapter 1-3DevOps Chapter 1-4- PM
DevOps Chapter 2-5DevOps Chapter 2-6DevOps Chapter 2-7DevOps Chapter 2-8DevOps Chapter 3-9ブログ執筆
良かったところ
- 9時間勉強できた!捗った(というかひたすら読んだ)
→継続する、イメージしながら読んでいく、インプットしたら必ずアウトプット
改善点
- 今日はToDoも進められたし、インプットもできたのであとはインプットした知識をアウトプットして長期記憶に保存する
→2週間に3回で長期記憶に保存することができるので、チェックを定期的にやることを怠らずにやっていく
ルーティン
- 8:00起床~9:00準備
- ~10:00移動
- 10:00学習室にて学習開始
- 10:30 Todoリスト作成
- 10:30~ Todoに取り組む
- 14:00~14:30昼食
- 14:30~ Todoに取り組む
- 21:15~ 食事
- 21:45~ブログ執筆
- 22:00~ 移動
- 24:30就寝
11/5 CI/CD 一気にアウトプット!
アウトプット項目
CI/CD 周りの学習
- DevOpsとは
- ConvDevとは
- アプリケーション開発ライフサイクルとその4ステップ
- Git hooks
- 集中型バージョン管理システムと分散型バージョン管理システムそれぞれの特徴 メリット デメリット
- ワーキングディレクトリ
- ステージングエリア
- ローカルリポジトリ
- ワーキングディレクトリ
- git config
- git init
- git add
- git status
- git commit
- git log
- git reset
- git branch
- git checkout
- git merge
- マージのログ表示
- git clone
- git remote
- git fetch/git pull
- アジリティ
- ビルド
- 継続的インテグレーション
- 継続的インテグレーション構築
- プライベートビルド
- 継続的インテグレーションに必要なもの
- TiDD
- WIP
- アップストリームファースト
- cron
- git-flow
- ZRF
- カバレッジとは
- インスペクションとは
- 警告を踏まえて修正する方法
- コードステップ数
- ビルド数制御の利点
- LDAP
- パラメータビルド
- マルチ構成プロジェクト
- ChatOps
- pipeline
- agent
- stage
- parallel
- phase
- 分散ビルドとは
- マスターとビルドエージェント
- パッケージリポジトリ
- インハウスリポジトリ
- ヒープ領域
- Jenkins 新規ジョブ作成
- ソースコード管理システム設定
- ビルド・トリガ設定
- ビルド後の処理設定
- ビルド実行
- 手動ビルド
- ユニットテスト自動化
- テスト結果の集計
参考
Todo
- AM
- Jenkins Chapter 5
- Jenkins Chapter 6
- Jenkins Chapter 7
- PM
- Jenkins Chapter 8
- Jenkins Chapter 9
- Jenkins Chapter 10
- Jenkins Chapter 11
- Jenkins Chapter 12
- Jenkins Chapter 13
- ブログ執筆
結果
- AM
Jenkins Chapter 5Jenkins Chapter 6Jenkins Chapter 7
- PM
Jenkins Chapter 8Jenkins Chapter 9Jenkins Chapter 10Jenkins Chapter 11Jenkins Chapter 12Jenkins Chapter 13ブログ執筆
良かったところ
9時間勉強できた!めちゃめちゃはかどった
→継続する
改善点
久しぶりに数をこなしてすすめることができたが、途中で集中力が切れてしまっていたことがあった
→淡々と受け止める!できることを淡々とこなすこと!集中力をうまく保つ。Befocued proを使用中なので、休む時間はしっかり休む。
ルーティン
- 8:00起床~9:00準備
- ~10:00移動
- 10:00学習室にて学習開始
- 10:30 Todoリスト作成
- 10:30~ Todoに取り組む
- 14:00~14:30昼食
- 14:30~ Todoに取り組む
- 21:15~ 食事
- 21:45~ブログ執筆
- 22:00~ 移動
- 24:30就寝
10/24 Docker 動画学習に関して
アウトプット項目
Dockerに関して
- Dockerとは
- 従来型の仮想化の構成要素と特徴
- コンテナ型の仮想化の特徴 従来型との大きな違い4つ
- コンテナの実行で動くもの(macの場合)
- dockerコマンドの動かし方
- 動く流れ
- docker run
- docker pull
- docker create
- docker hub
- イメージのタグの指定をしていないときのデフォルトのタグ
- dockerイメージとは
- dockerイメージのファイルシステム
- 階層構造の保存
- コマンド実行に伴う階層の増減
- 無駄なファイルが増えることのデメリット
- イメージの継承の特徴と利点
- イメージの後にコマンドをつなげる
- イメージ異一覧の表示コマンド
- タグ名の決まり
- イメージの削除
- イメージを使って作られたコマンドがある場合(そのコマンド)
- イメージの取得
- latestタグは最新?
- fortuneコマンド
- apt getコマンド
- -tオプション
- RUN命令
- CMD命令
- ビルドコマンド no cacheオプション
- ビルドコンテキスト
- ビルドコンテキストにあるファイルの流れ
- ビルドキャッシュとは
- Dockerにおいてpushとは
- pushの際Docker hubに同じ名前のタグのイメージがあった場合
- イメージのタグ付けルール
- docker pushコマンド
- docker hubからイメージを引っ張ってくる 見なければならない部分
- コンテナ立ち上げコマンド
- コンテナ名に関して
- -dオプション
- -pオプション
- コンテナの停止
- ホストマシンのディレクトリをコンテナにマウントする とは? やり方
- nginxのrun
- パスの指定のルール
- ホストマシン上のファイルをイメージ内にコピーする2つのコマンドとその違い
- 2つの中のベストプラクティスとそのコマンドの記述の仕方
- コンテナのライフサイクル 6つとそれぞれの状態にするためのコマンド
- コンテナのシェルに接続する 書き方
- 2つの抜け方と注意点
- 接続されているときにできること
- コンテナの状態をイメージとして保存する その時の注意点
- linkオプション
- -eオプション
- 自動ビルドの仕組みと手順 メリット
- docker-machine create コマンド
- docker-machine env default
- ホストにsshで接続する
- dockerホストのIPの確認
- マシン名を指定しない場合
- ブリッジドライバ
- docker network ls
- docker network inspect bridge
- ブリッジネットワーク
- ip addr show
- デフォルトのブリッジネットワークでできること
- デフォルトネットワークにおけるDNSの機能
- ユーザー定義ネットワークを使う方法
- docker network create ~
- docker network connect
- --networkの意味
- ネットワークを指定した場合の接続の特徴
- ネットワークからコンテナを切り離す
参考
Todo
- AM
- Docker Chapter 4
- Docker Chapter 5
- Docker Chapter 6
- PM
- Docker Chapter 7
- Docker Chapter 8
- Docker Chapter 9
- Docker Chapter 10
- Docker Chapter 11
- ブログ執筆
結果
- AM
Docker Chapter 4Docker Chapter 5Docker Chapter 6
- PM
- Docker Chapter 7
- Docker Chapter 8
- Docker Chapter 9
- Docker Chapter 10
- Docker Chapter 11
ブログ執筆
良かったところ
9時間勉強できた!
→継続する
改善点
今日はエラーの頻発で全く進まなかった
→淡々と受け止める!できることを淡々とこなすこと!
動画学習に関して
→実際時間がかかりすぎる部分があると感じる。本での学習の知識定着の流れ→本を読む→3語で得た知識をまとめて、後で振り返れるリストを作る→復習の際はリストを見ながら覚えているかどうかの確認→覚えていなければ本を確認し、リストに知識を自力で思い出せるくらいのヒントを付け加える→後日またチェックという流れなので、スクリプト等のない動画学習においては復習するときに覚えていなかった部分を確認するための本の部分を自分で作ることになるので非常に時間がかかる。→ある方のUdemyで学習→書籍で復習で非常に時間短縮ができるというtweetを見たのでやってみる。(書籍のみでもいいのでは?)→実践して自分なりの考えを持つ
ルーティン
- 7:00起床~7:40準備
- ~8:40移動
- 9:00学習室にて学習開始
- ~9:30 Todoリスト作成
- ~10:00 計一終了
- 10:00~ Todoに取り組む
- 12:00~13:00昼食
- 13:00~ Todoに取り組む
- 20:00~ 食事
- 21:00~ ブログ執筆
- 22:00~ 移動
- 24:00就寝
10/23 AWS Docker
アウトプット項目
AWSに関して
- NATの仕組み
- NATの2つの種類
- NATインスタンスとNATゲートウェイの違いと導入方法
- curlコマンド 意味と目的
- NATゲートウェイの削除
- mysqladminコマンド
- wordpress@"%"の意味
- TCP/IPモデル 階層の種類・役割・代表的なプロトコルと階層化の意図
- DNSサーバーによる名前解決の流れ
- TTL
- ジャンボフレーム対応
- MACアドレス
- ARP
- TCP/IPモデルにおけるルーター
- UDPとTCP 役割と適した場面
- 3ウェイハンドシェークとフラグ
- シーケンス番号と応答番号
- ネットワーク管理で必要な2つのこと
- デプロイツールの利点
- AWSでの管理の仕方とCloudFormation
- pingコマンド 応答の読み取り方と構文
- tracerouteコマンド 使う場面と特徴 構文
- telnet コマンド 構文
- nslookup, digコマンド 使う場面と構文
- ウェブサイトに接続できなくなったときのケーススタディ 使うコマンドの順序と意図 ※Dockerに関しては明日更新する
参考
Todo
- AM
- PM
- Docker 1
- Docker 2
- Docker 3
- Docker 4
- ブログ執筆
結果
- AM
- PM
Docker 1Docker 2Docker 3- Docker 4
ブログ執筆
良かったところ
9時間勉強できた!
→継続する
9時から学習できた
→初めての経験。習慣にする。継続!
改善点
エラーに詰まると時間がかかってしまう。
→見切りも重要。自分でやってみて最長1時間かけてわからなければ質問。自力である程度やることで力が付く場合もあるが時間をかければかけるほどではないことに注意する。エラーを調べて試しまくっているうちは実際に夢中になっていて集中している状態で、必ずしも悪いことではないがどれだけの時間をかけているか常に把握しきりあげる冷静な判断も必要。
Docker最後の部分終わらなかった
→動画学習が大学受験の予備校以来だったので、かかる時間を今日知ることができた。これを生かして明日も時間配分を考えた学習、Todoリスト作成をする。
ルーティン
- 7:00起床~7:40準備
- ~8:40移動
- 9:00学習室にて学習開始
- ~9:30 Todoリスト作成
- ~10:00 計一終了
- 10:00~ Todoに取り組む
- 12:00~13:00昼食
- 13:00~ Todoに取り組む
- 20:00~ 食事
- 21:00~ ブログ執筆
- 22:00~ 移動
- 24:00就寝
10/22 リスタート1日目
アウトプット項目
AWSに関して
- SCP
- 鍵ファイルのパーミッションの変更
- 踏み台サーバーの経由
参考
Todo
- AM
- wantedly プロフ作成 ←よく聞かれる質問をまとめる(用意すべき答えの質問) ←それに対する答えを用意する ←英語で書く
- PM
- 残りのタスク洗い出し
- ブログ執筆
結果
- AM
wantedly プロフ作成 ←よく聞かれる質問をまとめる(用意すべき答えの質問) ←それに対する答えを用意する ←英語で書く
- PM
残りのタスク洗い出しブログ執筆
良かったところ
- 9時間勉強できた、、、
→継続する、明日も、、、
- 昨日より早く起きた
→継続
改善点
- 夜はしっかりと寝る
→朝少し遅く起きた ←二度寝 ←十分な時間の睡眠を取ることで防ぐ ←あらゆる手段をもってして起きる
ルーティン
- 7:00起床~7:40準備
- ~8:40移動
- 9:00学習室にて学習開始
- ~9:30 Todoリスト作成
- ~10:00 計一終了
- 10:00~ Todoに取り組む
- 12:00~13:00昼食
- 13:00~ Todoに取り組む
- 20:00~ 食事
- 21:00~ ブログ執筆
- 22:00~ 移動
- 24:00就寝
10/21 AWS学習 リスタート
アウトプット項目
AWSに関して
参考
Todo
結果
- AM
計一
- PM
- 隙間
Pocket記事読む 5記事タスク管理ツールAsana(アサナ)とは?特徴や使い方を徹底解説Asanaはプロジェクト管理に最適。Slackとの連携など便利な使い方も解説Asanaの使い方・登録・料金・Slackタスク連携方法 | 無料でプロジェクト管理を全体スケジュール把握にはAsana PremiumがいいかもしれないAsanaを使っている人に伝えたい個人的お気に入りの使い方3選【日本語ガイド】Asanaの使い方のすべて。登録〜タスク管理まで解説直感的に使えるプロジェクトマネジメントツールAsanaの使い方「Asana(アサナ)」の評判と実態|15個のプロジェクト管理ツールを試してわかった本当のおすすめAsanaプロジェクト管理ツールAsanaの基本的な機能とおすすめポイントASANA(アサナ)ガイド基礎編 – Asanaの機能一覧Asana:全体像を把握しやすいタスク管理ツールAsana: タスクと仕事を整理
- 情熱プログラマー読む 20p
良かったところ
特にない、、、 もしあるとすれば特にないと思っているところ、、、
改善点
夜寝る、しっかりと寝る
→朝起きれなかった ←昨夜4時まで起きていた ←寝る、必ず寝る(今日は避けられないものがあった、けど、寝る)
朝もっとはやく起きる。
→二度寝しない
ルーティン
- 7:00起床~7:40準備
- ~8:40移動
- 9:00学習室にて学習開始
- ~9:30 Todoリスト作成
- ~10:00 計一終了
- 10:00~ Todoに取り組む
- 12:00~13:00昼食
- 13:00~ Todoに取り組む
- 20:00~ 食事
- 21:00~ ブログ執筆
- 22:00~ 移動
- 24:00就寝