Jのブログ

人生の記録

【読了】20160415-サーバインフラエンジニア養成本DevOps編

サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ] (Software Design plus)

DevOps導入時に一番大切なこと

  • 解決したい課題を確認
  • 優先順位をつける
  • 課題に対して決めること
    • あるべき姿
    • 現状分析、ゴールに対して何が足りないのか
    • 解決したか判断するためのメトリクス
    • スケジュール
    • 体制
  • 定期的に実施すること
    • 現状どうなっているかメトリクスの確認
    • 課題の棚卸
    • 優先順位をつける

DevOps導入ツール

  • コミュニケーションツール
  • バージョン管理システム
  • プロジェクト管理システム(チケット管理システム)
  • テスト自動化
  • CIツール(自動ビルドや自動テスト)
  • CDツール(ボタン一つでのデプロイ)
  • 開発/検証は仮想化ツールにより同じ環境で実施
  • プロビジョニングツール、構成管理ツールによる構築の自動化
  • 監視ツール
  • ダッシュボード(様々なメトリクスを見る)

継続的インテグレーションとは?

  • 目的は、テストを頻繁に実施することで早期に問題を発見し、品質向上すること
  • 各モジュール間で依存関係に対しても早期に問題を発見することが可能
  • バージョン管理システムより、ビルド、テストを自動化することで効率的な開発を行える

解決できる課題

  • ビルド、テストを効率的に実施できる
  • ビルドの属人化を排除できる
  • 特定の端末でしかビルドができないということがなくなる
  • 手順やドキュメントを更新せずとも、ノウハウンはCIツール上に集約できる
  • CIツールより、最新のビルドバージョンをダウンロード可能

仮想サーバのテンプレートレイヤー

Instructure as Code実現のポイント

  • 事前に要件を整理
  • いきなりすべてを自動化しようとしない
  • チームのスキルを考慮してツールを選択
  • 自動化コードは常にテストする
  • 自動化コードが失敗した場合に、それ以降を手作業で実施しない
  • これらをチームメンバに徹底する

Immutable Infrastructure

  • 一度構築したインフラは変更しない(インストールパッケージ、バージョン、設定)
    • 更新する場合は、新規で1からインフラ構築しインフラごと入れ替える
  • メリット
    • すべてのサーバが同じ状態になることを保証
    • 作りなおすことが前提となるため、バージョン差異等考慮しなくて良くなり、自動化コードがシンプルになる
    • Blue/Greenデプロイを行い、切り戻しが容易になる
  • 注意点
    • 頻繁にサーバを作り直すので、構築が自動化されている必要がある
    • 作ったサーバのテストも頻繁に実施するため、テストの自動化をする必要がある
    • サーバを捨てる前提のため、ステートレスなアーキテクチャ(データをサーバに保管しない)、ログを外部保管することが必要。データベースはRDS等のマネージドサービスを利用する。

2017年の目標

2016年の振り返りと2017年の目標まとめ

まずは、2016年の振り返りから。

2016年の振り返り

2016年は目標立ててない気がするし、立てた気もしないでもないがメモが残ってない。何も覚えてないので目標に対する振り返りはできないので総括的な感じで。

仕事

  • チームリーダーになった。組織について考えることに目覚めた。
  • 案件を沢山こなした
  • re:Invent最高だった、英語できなすぎて悲しくなった
  • 今後は案件を組織的に効率化して、余った時間でスケールに対する活動をしていきたい

プライベート

  • 9/22に次男が爆誕。ゆみ母、淳母が来た
  • 筋トレを始めたが1ヶ月でやめて、リバウンド
  • 自転車にあまり乗れなかった、ジョギングもあまりできなかった、結果ダイエットできてない
  • 家族旅行2回、鴨川シーワールド、大洗水族館
  • 車買った

2017年の目標

仕事

  • ブログを4本/月書く
  • 社内改善を3つする、ビジネスに貢献する
  • 本を5冊読む、PM、組織マネジメント
  • Python使いになる
  • MySQL使いになる
  • re:Invent行く

プライベート

30歳、脂肪との戦い

ダンベルでダイエットメニューを考えてみる

どうもiron千葉です。 夏も過ぎ去り涼しくなってきたので、サボっていたダイエット再開しようと思います。

で、ダンベル1セットあったのですがもう1セット買ってきました。 これで両手で同時10kgまでのトレーニングならいけます。

まずは3ヶ月続けて、お腹のぷよぷよ脂肪とおさらばしたいです。 なので、年末までには体作って体力も作りたいと思います。 会社・家庭での仕事もバリバリこなしたいです!来年の色々な活動のベースにできたらいいですね。

前置きはこれくらいにして、メニューを考えます。 条件は、

  • ダンベル
  • トータル30分くらいで
  • 可能な限り全身やる
  • 死ぬほどきついと、断念しそうなのでほどほどな感じで

というところです。

こちらを参考にさせて頂きました。

これをちょっと変えて、大きな筋肉を中心に鍛えることで効果を高めるように変更しています。

スクワット&ダンベルアップライトロウ

スクワット→ダンベルアップライトロウを続けてやることで、時間短縮を狙います。

ランジ&ハンマーカール

これもランジ→ハンマーカールの順で続けてやります。

デッドリフト&サイドレイズ

ダンベルプッシュアプ&キックバック

キックバックは横になりながらやる

サイドベント

これをワンサイクルで、1日2〜3回やってみます。 これを3ヶ月続けてみて、どれくらい効果があったかアップデートしようと思います。

まずは、やってみます!

6d mark2が出るまで待ち続ける①

どうも千葉です。

やっぱり、フルサイズ憧れますよね〜 私の場は、丁度1年前に70dを購入しました。

それからというもの、一眼で子供の写真を撮るのにはまっています。

いい形で、その瞬間を残したい。 そう思っていく中で、やはりフルサイズという存在が大きくなってきました。

フルサイズは、センサーサイズが大きく、光を多く捉えることができるのでノイズが少ないという話を聞きます。 また、階調のよさ。大きなボケで、立体感が生まれます。

妄想が妄想を呼び、物欲が最高潮になってます。 でも、今6dを買うのは微妙な所。たぶん、後1年を待てばmark2が出るという噂です。

6dも、めちゃめちゃいいのですが、ここはグッと我慢です。 1年間貯金して、パーッと6d mark2を買うことをここで叫んでおきますw

レンズも新しいのでないかなー。24-105mm F4L Ⅱとか。 純正以外だったら、シグマの24-70 F2.8の新しいのとか。

こっちも来年に発売されてて、もっと綺麗に瞬間を残したいなーと思います。 そのために、我慢我慢。今買うべきじゃない。 そして、自販機でジュース買うのやめます。タバコは去年やめたので、結構節約できてます。 あー、早く手にしたいw

もし、同じような状況の人がいたら、「来年まで待つ!」とコメント欄にでも書き込んで一緒に待ちましょう! そして、6d mark2を所持して笑顔になりましょう。

是非、コメント欄に高らかに宣言してみてください。 是非一緒に、じっと待ちましょう ^-^*)/

2015年度の目標再整理

完全個人的なメモです。 1つクリアできたので再整理。

仕事

  • AWS ソリューションアーキテクトプロフェッショナル取得【クリア】
  • AWS SysOpsアソシエイト取得
  • 応用情報技術者取得
  • 最新技術動向チェック再開(Feedly、rebuildfm)

プライベート

  • iアプリをリリースする
  • 英語力向上(NHK英語、TOEIC
  • 泊まりがけで家族旅行
  • カメラ貯金(来年出るであろう6dmark2を買うために)※自販機でジュース買わないとか頑張る

健康

  • ジョギング(週3時間は走る)
  • 筋トレ(最低週1回、テレビ見ながらやる)※筋肉SEを目指す【謎】
  • 酒は金曜日・土曜日(平日は家で飲まない)
  • 野菜中心の夜ご飯

【応用情報技術者】【ストラテジ】RASISとは

どうも、トニーです。

今日は、システムの信頼性を評価するためのRAISISについてです。 評価ということで、この観点の観点にもなると思います。

RAISISは、以下の頭文字

  • R:Reliability 信頼性
  • A:Availability 可用性
  • S:Serviceability 保守性
  • I:Integrity 保全性・完全性
  • S:Security 機密性

Reliability(信頼性)

  • 故障や不具合の発生のしにくさを表す
  • MTBF(Mean Time Between Failures)で表す
  • MTBFは、稼働時間当たりの障害発生回数:5年で5回の故障の場合、1年に1回故障するという計算になる

Availability(可用性)

  • 障害や保守による停止時間の短さを表す
  • 稼働率で表す
  • 稼働率は、全時間に対する稼働時間の割合:稼働時間(全運転時間-故障時間) / 全運転時間、24時間中12時間故障が発生した場合は、(24-12)/24 = 0.5

Serviceability(保守性)

  • 障害復旧やメンテナンスのしやすさを表す
  • MTTR(Mean Time To Repair)で表す
  • MTTRは、障害発生から復旧までの平均時間:例えば、3回障害が発生した場合、合計復旧時間/3となる

Integrity(保全性・完全性)

  • 過負荷時や障害時のデータの破壊や不整合のおきにくさを表す

Security(機密性)

  • 外部からの侵入・改ざんや機密漏洩の起きにくさを表す

(((( ;°Д°))))

【応用情報技術者】【法務】PL法(製造物責任法)とは

どうもトニーです。

製造物責任法について簡単にまとめます。

製造物責任法PL法)とは、製造物の安全性の欠陥により消費者側に被害が生じた際に製造業者の損害賠償の責任について定めている。 これは、被害者の保護を目的とする。

ということで、製造物責任法の対象は製造物です。製造物責任法では製造物は、製造または加工した動産(不動産以外の物や財産)と定義されています。 つまり、サービス、不動産、未加工のものは対象外です。プログラムも物体ではないので対象外。 ソフトウェアを組み込んだハードウェアの場合、たとえソフトウェアに欠陥があった場合でも、製造物責任法ではハードウェアに欠陥があったとみなされます。

(((( ;°Д°))))