Kush's Wiki

Sort by - linked count

• サービスディスカバリ
  アプリケーションサービスを公開する際、クラウドネイティブなコンテナアプリケーションをステートレスに扱うようなケースで、アプリケーションの場所（IPアドレス）を容易に提供するためのパターン
• メッセージキュー
  #Data Processing イベントストリーム処理において、Pub/Subの間に配置されイベントをキューイングする役割。 基本としてイベントをコンシューマーと1対1でやりとりし処理が完了したらイベントが削除される実装がある。（Amazon SQS等） 対しログベースのメッセージキューはコンシューマーと1対Nでやり取りし古いイベントのリプレイも可能である。（Amazon Kinesis Stream等） https://aws.amazon.com/jp/message-queue/
• Infrastructure as Code
  Infrastructure as Code #Continuous Integration #Continuous Delivery インフラストラクチャとしてのプロセスや環境、設定等をコードで管理し文書化する方針 Infrastructure as Code とは - IaC の説明 - AWS
• スプリントレビュー
  #スクラム #Agile #スプリント 最新のスクラムガイドより抜粋 スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。 検査、適応を行うためのイベント
• GitOps
  Weaveworks社によって提唱された、Cloud Nativeの文脈においてgitを用いた設定管理を行うようなContinuous Delivery手法 対象は主にKubernetesとなる
• kube-proxy
  
• Tom DeMarco
  #Person
• OAuth2
  #Security #API Architecture #Authorization RFC6749によって定義された認可フレームワーク 主に以下の定義を利用する リソースオーナー（Resource Owner） 保護されたリソースへのアクセス許可を行うエンドユーザー リソースサーバー（Resource Server） 保護されたリソースを所有するサーバー、アクセストークンを受け取り検証する クライアント（Client） リソースオーナーによる認可の委譲先、アクセストークンを使ってリソースサーバーへリクエスト可能 認可サーバー（Authorization Server） リソースオーナーの認証・アクセス許可時に認可グランドを返却したのち、クライアントにアクセストークンを発行する 初回アクセストークン利用までのプロトコルの流れは以下 Protocol Flow リソースオーナーによるアクセス許可時に認可サーバーが返す認可グランドは、認可コードが利用されることが多い RFC 6749 - The OAuth 2.0 Authorization Framework
• Base64
  元の文字列から英数字のみの結果を出力するエンコード方式 例としてJSONで用いられる波括弧やダブルクォーテーション等の特殊文字を適切に扱えるよう、英数字のみの値に変換する RFC 4648 - The Base16, Base32, and Base64 Data Encodings
• KMS
  Key Management System #Security 暗号化キーのディスカバリ、保存を行う管理システム。暗号化はKMS外で行う前提
• 実例マッピング
  Example Mapping #Documentation Agile Testing、BDDで紹介されるプラクティス。 マッピングする付箋の種類には Story Rule Example Question の4種があり、あるStoryにおけるExample（実例）を軸に、定められるRuleと残論点としてのQuestionをマッピングする 【翻訳記事+α】受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」 今日から使える「実例マッピング」
• State of DevOps Report
  DORAによって毎年出されているDevOpsの状況に関する報告書
• Google Cloud/

  GKE
  
• ストラングラーフィグアプリケーション
  StranglerFigApplication #Continuous Integration Martin Fowlerによる理論。既存のシステムを置き換える際、既存のシステムの周辺に新規のシステムを追加していき段階的に置き換える。 イチジクの成長段階に似ていることからFigの命名を含んでいる。 原文はこちら
• Linux Foundation
  Linuxのようなオープンソースソフトウェアやテクノロジーを支援、促進、保護、標準化するコミュニティ https://www.linuxfoundation.org/
• テストダブル
  #Testing 自動テストに使用する代用品のこと、モックと呼ばれるようなものの総称
• IDL
  Interface Definition Language #Programming
• Buf
  
• コンプリケイテッド・サブシステムチーム
  #Team Organization チームトポロジーにて紹介される4つのチームタイプの内の1つ 認証や認可・決済等のサブシステムを構築しストリームアラインドチームにAPIを提供する
• 仮説キャンバス
  
• プラットフォームチーム
  #Team Organization チームトポロジーにて紹介される4つのチームタイプの内の1つ 機能横断的なインフラやツール、ライブラリ等をを実装しストリームアラインドチームにAPIを提供する
• 受け入れ条件
  #Agile #Documentation プロダクトバックログアイテムが完成したと判断できる条件
• LeanとDevOpsの科学
  
• Ward Cunningham
  
• MapReduce
  #Data Processing Unixのプロセスと同様の特徴を持つ分散ファイルシステム上のバッチ処理フレームワーク。 MapReduceジョブは以下の2つに分かれる Mapper 分散ファイルシステムの各レコードからキーと値のコレクションを抽出する Reducer mapperによって生成されたキーと値のコレクションからコレクションに対するイテレータとともに関数を適用し出力レコードを適用する HadoopのMapReduce実装ではHDFS(Hadoop Destributed File System)と呼ばれる分散ファイルシステムが用いられる
• SIGKILL
  強制終了のシグナル シグナルの値は9
• エラーバジェット
  #Reliability リリース可否を決めるための指標となるような考え方。 SLOを満たせない時間を名前の通り予算として管理する。 エラーバジェットが残っていればリリース可能、エラーバジェットを使い切っていればリリースはストップしシステムの改善を行うというような運用をする。 エラーバジェットによってプロダクト開発者とSREでイノベーションと信頼性のバランスを適切に扱う
• プログラマーの誓い
  #Robert C. Martin Clean Coder Blog
• OLTP
  Online Transactional Processing #Data Store ACIDを遵守し、高い可用性・信頼性を満たすべきシステムに対して用いられる言葉
• プロダクトバックログアイテム
  #Agile プロダクトバックログ上で生まれるアイテム、要件、テストなどをまとめるハブになる
• ADR
  Architectural Decision Records #Documentation アーキテクチャに関する意思決定とその理由を記録する文書。意思決定に際する文脈、根拠、その決定による成果物等を記述する ADRはなぜそのアーキテクチャを選出したかの意思決定を理解するのを助ける。 ADRはチームメンバーの誰もが作成できる。ただしオーナーシップとしてAuthorは明確にする必要がある。初期ステータスは Proposed とする。 次に他チームメンバーによるレビューを行う。修正すべき点がある場合は Proposed のままアクションのアサインを行う。このときアサインはチームメンバーの誰でもよい。ADR自体はRejectする場合はステータスを Rejected にしADRのライフサイクルは終了する。 レビューを経て全てのアクションが完了した場合、ステータスを Accepted にする。一度AcceptされたADRはイミュータブルに扱い変更はしない。 Architectural Decision Records (ADRs) ADR process - AWS Prescriptive Guidance
• クリーンアーキテクチャ
  
• 経験主義
  実際の経験と獲得している知識に基づいて意思決定をする考え
• Linux Capabilities
  rootユーザーが持つ特権を細分化したもの Non-root Userへ必要最小限のケイパビリティを割り当てる方法は、Dockerのセキュリティベストプラクティスとして紹介されている Linux Capabilities Docker のセキュリティ — Docker-docs-ja 1.12.RC2 ドキュメント
• Book/

  エクストリームプログラミング
  
• Book/

  チームトポロジー
  
• Knative
  
• Seb Rose
  
• STRIDE
  #Security セキュリティ脆弱性をカテゴライズするような脅威モデリングでの方法論 Microsoft Threat Modeling ToolではSTRIDEを利用していくつかの自動分析を行うことができる STRIDEは以下の頭文字を取ったもの Spoofing（なりすまし） Tampering（改ざん） インジェクション攻撃 マスアサインメント攻撃 Repudiation（否認） Information Disclosure（情報漏洩） 過剰なデータ露出 不適切なインベントリ管理 Denial of Service（サービス拒否） Dos攻撃 Elevation of privilege（権限昇格） https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats#stride-model
• Ron Jeffries
  #Person Home
• コラボレーションモード
  #Team Organization チームトポロジーにて紹介される3つのチーム間インタラクションの内の1つ チーム間で短期的に密なコミュニケーションを行う、境界は曖昧な状態だがイノベーションの原動力になる
• Greg Young
  
• リーン
  #Agile トヨタが源流となるリーン生産方式をソフトウェア開発に適用している リーンソフトウェア開発には7つの原則がある ムダをなくす 品質を作り込む 知識を作り出す 決定を遅らせる 早く提供する 人を尊重する 全体を最適化する
• パーセンタイル
  #Reliability 指定するパーセントのリクエストが何秒以内に処理された、といったようなケースで用いる値 代表的な例として中央値は50パーセンタイル値である
• Four Keys/

  サービス復元時間
  Time to Restore Services #DevOps
• Four Keys/

  変更障害率
  Change Failure Rate #DevOps
• Four Keys/

  デプロイの頻度
  Deployment Frequency #DevOps
• Argo
  
• 振る舞い駆動開発
  振る舞いをベースにテストをし開発を進めようという考え Testing, TDDそれぞれの文脈で用いられている
• デイリースクラム
  #スクラム #Agile 最新のスクラムガイドより抜粋 デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。 全員で以下のフォーマットを共有する 昨日やったこと 今日やること 障害となっているもの