kuzira_diver

書籍名： 『オライリー 入門 監視』（著者：Mike Julian） 日時：2019年3月7日～3月31日 Before 監視はインフラエンジニアが片手間でするようなものだろうか？ NWエンジニア、DBエンジニアはいるのに監視エンジニアはなぜいない？ そもそも監視を学べる機会・本が少ない。など、色々な悩みを抱えていた時に、 『オライリー 入門 監視』 を手にした。 今まで自分がやってきた監視が正しいのか、間違いだったのか、この本で見極めようと思う。　 気づき 1章　監視のアンチパターン アンチパターンとは、一見よいアイデアだが実装すると手痛いしっぺ返しをくらうものをいう。 ツール依存になっていないか。 監視とは複雑な問題をひとくくりにしたもの、専門化されたツールが複数あって良い。 監視Agentは詳細な情報をもたらしてくれる。 小さく何かに特化したツールなら作る選択肢も。pythonコードのスクリプトなど。 役割をもつ全員が監視に責任を持つべき 。 アプリエンジニアはソースコードのどこに監視のポイントがあるか、ネットワークエンジニアならネットワーク監視の勘所が一番詳しいはず。 「動いている」かを監視する。リクエストが200 OKか？文字列は正しいか？レイテンシは増大していないか？ アラートに関してはOSのメトリクスはあまり意味がない。CPU使用率が99％でも、正しく動いていれば良い。ただし分析・診断には必要。 メトリクスは高頻度（最低でも60秒）で取らないと意味がない。保存期間に応じてデータの間引き設定を忘れないように。 監視設定にも手動ではなく、自動化を。 従来型環境は個別に何かを監視していたが、クラウドは集合体（複数システムのまとまり）として監視するよう変わってきた。 まとめ ツールに依存しても、監視の仕組みは良くならない。 監視は全員がやるべき仕事。チームや部署内での役割ではない。 素晴らしい監視は、チェックボックスに「これは監視しています」とチェックを入れるだけで済むものではない。 2章　監視のデザインパターン 組み合わせ可能な監視⇒専門化されたツールを複数使い、監視プラットフォームを作ること。 代表的なものGraphite, Sensu, logstas...

書籍名：『学びを結果に変えるアウトプット大全』（著者：樺沢紫苑） 日時：2019年1月31日～1月31日 Before 　IT業界に身をおく中で、技術動向や自信のスキルアップは常に必要です。独身時代は自分に使える時間は多くありましたが、結婚や年齢を重ねる毎に様々な理由により時間が制限されてしまいます。その為、短い時間で効率よく学習する必要があると考え、この 『学びを結果に変えるアウトプット大全』 を手に取りました。 　 気づき／メモ CHAPTER1 アウトプットの基本法則【RULES】 得た知識はアウトプットすることによって自己成長につながり、現実が変わる。 2週間に3回使った情報は長期記憶される。 インプットとアウトプットの比率は3対7、教科書より問題集を。 フィードバックにより、インプットの軌道修正を。 「短所克服」苦手を克服 「長所伸展」長所の延ばす。自信をつけさせる。 CHAPTER2 科学に裏付けられた、伝わる話し方【TALK】 話す - 読んだこと、聞いたこと、体験したことを話す。事実・感想・意見→あのお店に行った・○○を食べた・ヒットすると思う。など 上手く行っているチームはポジティブな言葉が多い。ネガティブな言葉の3倍。 悪口はストレス発散にならない。逆にストレスになる。 言語的コミュニケーションと非言語的コミュニケーション。メラビアンの法則：視聴覚55％、聴覚38％、言語7％⇒笑顔で堂々と話そう！ アイコンタクトがあると脳が活性化、重要なポイントは目を合わす。 クッション話法 Yes But話法 良い話しの後に悪い話をいれる。「~がんばっているね。けど〇〇ができていないので、カイゼンしよう。」 Yes And話法 プラスの情報にプラスを上乗せする。「~がんばっているね。〇〇するとさらに良いね。」 Yes How話法（ 部下の行動をカイゼンさせる効果的な手法 ） 疑問形式で本人に考えさせる。「~好調だね。どうすればもっと伸ばせる？」 No But話法（ダメな話し方） ネガティブな話をしてからポジティブな話をしても、ネガティブな印象だけが残ってしまう。「○○ができていないじゃないか、~はがんばっているのに。」 挨拶は「アタナを認めています」の...

情報処理安全確保支援士　オンライン講習を受けた備忘録 内容：情報処理安全確保支援士　オンライン講習C 日時：2019年2月 1章　情報セキュリティ重大脅威とは 「攻撃の手法」「攻撃の目的」を知り最新の情報を知ることが大切。 組織向けは2017年と比較してビジネスメール詐欺が増加。 個人向けは「偽警告によるインターネット詐欺」がランクイン。 マルウェア感染させる手法はメールで送付するやり方から、ダウンロードさせたり、水飲み場型攻撃などの手法へ変化。また対象機器もPC・スマートフォンからIoT機器へ移り変わってきている。 hacktivism(ハクティビズム)とはアクティビズムとハックを掛け合わせた造語。 2013年以降は組織内部の犯行による情報流出と共に犯罪者の低年齢化が進む。 犯罪の目的80％が不正送金・不正購入。 10大脅威の傾向①IoT機器に関する脅威②人がもつ脆弱性③犯罪のビジネス化④仮想通貨 ①IoT機器に関する脅威 ID/PWが初期設定のまま 修正プログラムを適用しない ネットワークと繋がっている認識が低い マルウェア「Mirai、BASHLITE」 DDOS攻撃に利用「IoTRoop、IoT_reaper」 脆弱性のある機器を見つける検索エンジン「SHODAN、Censys」 ②人がもつ脆弱性 ソーシャルエンジニアリング 運用管理の不備 不明確な担当者 情シス部門が管理できていない機器（ウェブカメラ、複合機） 不正ログインの手口 パスワードリスト攻撃 パスワード推測攻撃 ウイルス攻撃 対策 パスワードを長く、複雑にし使いまわさない。 パスワード管理ソフトの利用 多要素認証、サービスが推奨する認証方式 利用をやめたサービスの退会 「高度標的型攻撃」対策 に向けたシステム設計ガイド  ③犯罪のビジネス化 ランサムウェアによる被害 インターネットバンキング・クレジットカード不正利用 ビジネスメール詐欺による被害 ワンクリック請求等の不正請求 ④仮想通貨 マルチシグ（マルチシグネチャ）対策がとられていない交換所・ウォレット 各業者に依存したセキュリティレベル GDPR（一般データ保護規則）ー EU版の個人情報保護法 データ主導経済　①...

日時：2019年1月31日　18:50～ 内容： Mix Leap Study #32 - めっちゃわかるAIとKubernetes（GCPUG共催） Kubernetes と Yahoo! JAPAN の取り組み 資料 kubernetes クバネテス kubernetes 3ヶ月に一度のマイナーバージョンアップ yahoo 200+ kubernetesクラスタを運用 kubernetes as a Service をZラボが提供 Linuxコンテナ　システムの他の部分から分離されたプロセス。プロセスがシステムの他の部分に影響しないように隔離し、制限。 Docker　コンテナの実行と管理を行うソフトウェア。ソフトウェアの開発を変えた。 イミュータブルでポータブルな性質だから、自動化・スケジューリングがしやすい。 kubernetesはポータブルである。⇒どの環境で動く kubernetesは成長している。⇒他のマネージドよりも利用者数が多い。 なぜkubernetesか？機能面 頻繁なデプロイに耐えられる非常に優れた機能を持つ 時間のかかるデプロイは問題があったときにの修正も遅れる。 頻繁なデプロイは問題もすぐ修正でき、リスク低 宣言的設定→以前は順番に変更（インストール・デプロイ）をしないといけなかったが、「のぞましい状態」を記述した設定ファイルを反映する。宣言的設定によるロールバック。 自己回復機能「セルフヒーリング」→障害時（ノードが死んでも）に自動回復する。 コンテナ中心のインフラ サーバリソースの隙間問題の解決 vmの抽象化に加えて、itインフラも抽象化（ロードバランサーや永続ストレージ） kubernetesオブジェクト　ワークロードやITインフラをアプリケーション指向に抽象化したもの Pod　複数コンテナと、ボリューム。デプロイの最小単位 ReplicaSet　コンテナの数を管理 Deployment　デプロイを管理。内部的にはReplicaSetを使用。 Service　仮想IPとポートを持ち、ラベルセレクタによるPodのグルーピングを行う。Service名によるサービスディスカバリ。 minikube　ローカル開発用クラスタ開発 アプリケーションを Kubernete...

20181213_AWS re:Invent 2018 ダイジェスト　～AWSの最新動向を学ぶ～ 日時：2018/12/13 9:15 - 17:30 カンファレンス：AWS re:Invent 2018 ダイジェスト　～AWSの最新動向を学ぶ～ 内容： ■特別講演 re:Invent 2018 サマリーと新サービス概要 ・今回のコンセプト 今回のキーワードは『Builders』。 ITを駆使したモノづくりを行う人達すべての総称とし、サービス、モノ、お金の流れ全てをAWSがサポートする。 モノづくりに必要な環境・リソースを用意し、必要な時に必要な分を提供（従量課金）し、Buildersに自由な選択肢を提供する。 ・新しいサービス 人工衛生からロボティクス・機械学習までAWSがマネージド環境を用意しており、本気度が伺えた。 また機械学習は実験段階から既に活用し、利益に繋げていける段階まで来ている。 上記のような専門的な分野だけではなく、M&Aによる独自チップ・プロセッサの開発も行っており、既存クラウド環境の価格改定にも力を入れている。 ■Compute/Networking セッション 特に目を惹いたのが「Global Accelarator」「Outposts」である。 「Global Accelarator」はマルチリージョンでもフェイルオーバーでIP固定でき、同じIPをグローバルで利用可能。どこにいても一番近いエッジロケーションに同じIPでアクセスできる。ビジネスのグローバル化を意識させられるサービスとなっている。 「Outposts」AWSが設計したサーバラックをオンプレミスで利用可能。マネージドコンソールで操作可能となっている。ハイブリッドを謳っていたが、エッジコンピューティングを意識したサービスだと思われる。 ■マシンラーニング　Other new service 各サービスとも、マネージドサービスを提供することで、マシンラーニング敷居をかなり下げた印象があった。 ■Database 『Quantum Ledger Database』（台帳DB）などは今までパブリッククラウドへの移行を躊躇っていた業種（金融・官庁）向けたメッセージ（戦略）となると思われる。 全体で言えることだが、様々な業種にお...

会社では教えてくれないビジネスモデル。 自力で学ぶために『ビジネスモデル・ジェネレーション』を選んでみた！ Canvas ビジネスモデルとは、どのように価値を創造し、顧客に届けるかを論理的に記述したもの。 4つの領域（顧客、価値提案、インフラ、資金）と９つの構築ブロック（顧客セグメント、価値提案、チャンネル、顧客との関係、収益の流れ、リソース、主要活動、パートナー、コスト構造） [顧客セグメント]　企業が関わろうとする顧客グループについて定義。ニーズ、行動、態度によってグループ化。 [価値提案]　特定の顧客セグメントにむけて、価値を生み出す製品とサービス。新規性、パフォーマンス、カスタマイゼーション、仕事を終わらせる、デザイン、ブランド、価格、コスト削減、リスクの低減（SLA遵守）、アクセスしやすさ、快適さ／使いやすさ [チャンネル]　顧客セグメントとどのようにコミュニケーションし、価値を届けるか。 チャンネルフェーズ：認知＞評価＞購入＞提供＞アフターサービス [顧客との関係]　企業が特定の顧客セグメントに対して、どのような種類の関係を結ぶか。顧客セグメントがどんな関係を構築、維持してほしいと期待しているのか。どれだけのコストがかかり、ビジネスモデルの他の要素とどう統合されるのか。  [収益の流れ]　企業が顧客セグメントから生み出す現金の流れ。顧客はどんな価値にお金を払うのか。価格メカニズム→固定メニュー価格と変動価格。 [リソース]　ビジネスモデルの実行に必要な資産。物理的なリソース、知的財産、人的リソース、ファイナンスリソース [主要活動]　企業がビジネスモデルを実行するうえで必ず行わなければならない重要な活動。 [パートナー]　ビジネスモデルを構築するサプライヤーとパートナーのネットワーク。 [コスト構造]　ビジネスモデルを運営するにあたって発生するすべてのコスト。 パターン [アンバンドルビジネスモデル]　企業のコンセプトは顧客ビジネス、製品ビジネス、インフラビジネスの３つのビジネスタイプが存在する。それぞれは対立するため、異なる法人へ分社化するのが理想。 [ロングテールビジネスモデル]　多くのものを少しづつ販売するモデル。ニッチ製品。 [マルチサイドプラットフォーム]...

SRE（サイトリライアビリティエンジニアリング）の備忘録 徹底と献身、準備とドキュメンテーションの価値を信じること。 運用（定型）業務の合計を50％以下に。 明文化が大切（業務、環境）。 ポストモーテム→事後検証・振り返り、レビューの重要性。 エラーバジェット[許容可能なエラー率（時間、範囲やレベル）]→いかなる場合でも100％を目指すのは間違い。 1章 モニタリング→サービスの健全性と可用性を追跡（アラート、チケット、ロギング、有効な出力）。 変更管理の自動化→繰り返しタスクに対して疲労、慣れ、軽視、不注意といった一般的な問題を回避。 3章 稼働時間を最大化するよりも、可用性におけるリスクとイノベーションの速度、およびサービス運用の効率性とのバランスをとる。 停止時間よりもリクエスト成功率を可用性の定義とする。 可用性はサービスが提供する機能と市場におけるサービスの位置づけによって決まる。 カナリアテストを組み込む設計 SLO－稼働時間＝損失可能な信頼性 4章 SLI/SLO/SLAの違い SLOは『SLI ≦ ターゲット、もしくは下限 ≦ SLI ≦ 上限』 5章 トイル≠やりたくない仕事 雑務＝オーバーヘッド ただし、つまらない仕事には長期的な価値があることも。 トイルの定義 サービスを稼働させることに関係のある作業 手作業で繰り返し行われ  自動化する事が可能 戦術的で長期的な価値を持たず 作業量がサービスの成長に比例する傾向を持つ 6章 4大シグナル→レイテンシ、トラフィック、エラー、サチュレーション（システムリソースの利用率） ページに人が対応するという事は未来のシステム改善にあたる時間が無くなるという事。 11章 運用の負荷を計測（日々のチケット、インシデントなど） 28章 SREの教育方法『推奨されるパターン』と『アンチパターン』、特にアンチパターンは普段の業務で行っていないか参考になる。 『オンコールとその先へのSERの立ち上げの設計図』（抽象的↔実践的方法） 意識的に理論と実践を適切に組み合わせて学習させる。 学習とプロジェクトを担当させることで、目的と生産性の感覚を身につかせる。 30章 正式なSLI/SL...