Sort by - linked count
-
Kubernetes
-
Person人物のまとめ
-
Book書籍のまとめ
-
Blog技術ブログや記事のまとめ
-
DevOps capabilitiesDORAによって報告されているFour Keysにおけるソフトウェアデリバリの高パフォーマンスチームが兼ね備えている複数のケイパビリティ 当初は24個で24 key capabilitiesと呼ばれていたが、State of DevOps Reportのアップデートによって内容は変化している DORA | Capabilities DevOps
-
Go
-
Kubernetes/Pod
-
HTTPHypertext Transfer Protocol #Network
-
DevOps2009年に10+ Deploys Per Day: Dev and Ops Cooperation at Flickrにて初めて登場した言葉 開発とオペレーションを一つのチーム内で両立させる 広義な用語ではあるが、共通して以下のような手法が定義されることが多い #Continuous Integration #Continuous Delivery Infrastructure as Code マイクロサービス
-
Claude Code#Programming #LLM CLIで直接動作する会話型エージェント型コーディングツール Anthropic社が提供しClaudeモデルの利用を前提にする IDEとの統合が可能 https://docs.anthropic.com/ja/docs/claude-code/overview
-
CNCF
-
Kubernetes/リソースRESTfulなKubernetes APIでリソースとして扱われるオブジェクト
-
Platform EngineeringTeam Topologiesのプラットフォームチームをきっかけとして登場した分野 開発者の認知負荷の増大を防ぎ、生産性の向上を目指す DevOps
-
コンテナ#Cloud Nativeアプリケーションの基本要素 OOPと比較すると、コンテナイメージはクラス定義でコンテナはインスタンスのような関係性
-
ドメイン駆動設計Domain Driven Design #Software Design ドメイン(事業領域)ファーストでプロダクト設計を行う考え方 エリック・エヴァンスのドメイン駆動設計にて初めて紹介された
-
スクラム#Agile
-
Rust#Programming Rust Programming Language
-
BDDBehavior-Driven Development #Testing #Agile #Product Management Dan NorthがTDDのビジネス要件との乖離の課題を解消するために名付けた考え、2006年にIntroducing BDDによって紹介された その後のコミュニティの成熟でGherkin記法の実践だけではなく、どのようにビジネスチームと一緒に製品を作り上げていくのか、に焦点が当たっている 主に以下の3つのプラクティスを行う 発見 定式化 自動化 https://cucumber.io/docs/bdd/
-
LLMLarge Language Model
-
マイクロサービス#Software Design #API Architecture DDDにおける境界づけられたコンテキストに対応する形でサービスを用意し、サービス間通信を行う設計パターン マイクロという名前の通り、サービスインターフェースが小さく疎結合になっていて各サービスの責務が凝集されていることが望ましい
-
GitHubGit リポジトリのホスティングと開発コラボレーションを提供するプラットフォーム。Pull Request を中心とした共同開発・コードレビュー・Issue 管理を軸に、ソース管理から CI/CD・自動化までを一つの開発者プラットフォームとして統合する。2018 年から Microsoft 傘下。 https://github.com/
-
Team Topologies#Team Organization チームトポロジーにて完成形としてまとめられた、コンウェイの法則を中心に据えた適応型の組織設計モデル。DevOpsとも深く関連がある チームファーストな考え方で以下の4つのチームタイプを説明している ストリームアラインドチーム プラットフォームチーム イネイブリングチーム コンプリケイテッド・サブシステムチーム 最も中心となるのはストリームアラインドチーム それぞれのチーム間の関係性に関して3つのインタラクションモードが説明されている コラボレーション X-as-a-Service ファシリテーション
-
Datadog
-
Kubernetes/CRD
-
Docker
-
JavaScript#Programming
-
サプライチェーン攻撃#Security ソフトウェアの依存・ビルド・配布といった信頼された経路を侵害し、正規の配布物を通じて下流の利用者へ到達する攻撃 標的に直接侵入せず「信頼の連鎖」を悪用する点が特徴で、上流を 1 つ侵害するだけで多数の下流へ伝播する 攻撃者は正規の配布物に紛れ込むため、利用者側の通常の検証では気づきにくい 防御は信頼の検証可能化が軸: 構成要素の固定(pinning)、最小権限、由来の署名検証、依存構成の可視化(SBOM)
-
ログ#Observabilityにおけるテキストベースの記録 Observability Whitepaperを参考にすると、ログにはいくつかのカテゴリがある Application Logs Security Log System Log Audit Log Infrastructure Log またログレベルとして以下の4パターンがある ERROR WARNING INFO DEBUG
-
SASTStatic Application Security Testing #Security #Testing ソースコード、バイトコード、バイナリを解析してセキュリティ脆弱性を検出するテスト手法 ホワイトボックステストとも呼ばれ、アプリケーションを実行せずにコードを分析する 特徴 DevSecOpsのシフトレフトを実現 #Continuous Integrationパイプラインに統合可能 SQLインジェクション、XSS、バッファオーバーフロー等を検出 https://owasp.org/www-project-devsecops-guideline/latest/02a-Static-Application-Security-Testing
-
GitHub Actions#Continuous Integration #Continuous Delivery
-
Istio
-
分散トレース#Observabilityにおいて分散トランザクションの各コンポーネントで何が発生したかを追跡する、単にトレースと呼ばれることもある 各コンポーネントに対応するデータポイントはスパンと呼ばれ、分散トレースはスパンの集合を扱う Observability Whitepaper
-
メトリクス#Observability システムの状態を表すために収集された数値、例としてログを元に時間単位のHTTPリクエスト数をメトリクスとして収集する等 ログやトレースとは異なり詳細なデータは抜けているため、システムで何が起きているかの調査のスタート地点(アラート)となることが多い Observability Whitepaper システム状態を表すために収集されたスカラー値であり、オプションでタグが付与され、数値をグループ化したり検索したりすることがある オブザーバビリティ・エンジニアリング | P55
-
Protocol BuffersProtobuf #API Architecture #Programming Googleによって開発されたインターフェース定義によるバイナリエンコーディングライブラリ。インターフェース定義言語に分類される フィールド名のエイリアスとして扱うフィールドタグ(数値)によってバイトを節約している。 フィールドタグによる互換性に関する仕様の要点は以下。 フィールドの追加 未使用のタグ番号を割り当てることで前方互換あり 必須でなければ後方互換あり フィールドの変更 フィールド名の変更は前方・後方互換あり フィールドの削除 追加時の前方・後方と逆 またProtocol Buffersはフィールド制約である optional と repeated 間の互換性にも対応している。これはバイナリ上でフィールド情報を単純に複数回並べているため。 Protocol Buffers Documentation
-
JWTJSON Web Token #Security/Authentication トークン自体の情報(例: 期限)を自身で構造化して保持することで、共有データベースへ保持・検索をする必要がないトークン。トークンが自身の情報を持つことで外部からのトークン取り消しのような操作はできない JWTは.によって3つのセクションの文字列に分割できる(署名がない場合3つ目のセクションは空) それぞれのセクションの文字列は構造化されたJSONをBase64URLエンコードした結果となっている ヘッダー 1つ目のセクションはヘッダーとして以下のような構造を持つ { "typ": "JWT", "alg": "RSA256" } algで指定する署名アルゴリズムは3つ目の署名セクションの解読にて用いる ペイロード 2つ目のセクションはトークン自体のペイロードになる。ペイロードの中身はJSONであれば自由だが、JWTクレームと呼ばれる役割が明示・明示された項目群が存在する。 例として iss(発行者)、sub(対象者)、exp(有効期限)などがある 署名 3つ目のセクションはHMACやRSAのような署名アルゴリズムを使った結果が保持される RFC 7519 - JSON Web Token (JWT)
-
TLSTransport Layer Security #Network #Security/Cryptography 通信暗号化プロトコル ネットワーク通信開始時にTLSハンドシェイクによる通信の確立後、鍵交換を行いセキュアな通信を行う(ハイブリッド鍵システム) https://developer.mozilla.org/en-US/docs/Glossary/TLS
-
信頼性Reliability システムが障害(ハードウェア・ソフトウェア・人為的なエラー)が発生しても正しく動作し続けること
-
OpenTelemetry
-
Cookie#Security #Network HTTP通信において、セッション管理にいくつかのセキュリティ機能を提供する
-
Martin Fowler
-
Linux FoundationLinuxのようなオープンソースソフトウェアやテクノロジーを支援、促進、保護、標準化するコミュニティ https://www.linuxfoundation.org/
-
ロードバランシング#API Architecture #Network 外部からの大量トラフィックを捌けるよう用意された重複データを持つ多数のリソースサーバー群が均等に使用されるよう制御する役割 アプリケーションの可用性を高め、リバースプロキシと同様にサーバーを保護するセキュリティ機能が組み込まる ロードバランシングとは? - ロードバランシングアルゴリズムの説明 - AWS
-
SRESite Reliability Engineering Webサービスの信頼性に対してソフトウェアエンジニアリングの手法を適用する分野
-
Infrastructure as CodeInfrastructure as Code #Continuous Integration #Continuous Delivery インフラストラクチャとしてのプロセスや環境、設定等をコードで管理し文書化する方針 Infrastructure as Code とは - IaC の説明 - AWS
-
gRPC
-
サービスメッシュ#Network #Observability #Security #API Architecture マイクロサービスで行われるようなサービス間通信をルーティング、監視、保護する機能を提供する Kubernetesにおいてはクラスタ単位でサービスメッシュを構築する サービスメッシュはクラスタ内の全てのサービス間通信を制御するコントロールプレーンとコントロールプレーンで指定された作業が実行されるデータプレーン(サービス)の2つの基本要素を持つ。
-
DevOps capabilities/Fast FlowDevOps capabilitiesのうちの分類の一つ
-
スクラムガイド#Agile スクラムのフレームワークを定義しているドキュメント、2020年版が最新 Jeff Sutherland, Ken Schwaber によって作成された Scrum Guide Scrum Guide(ja)
-
MySQL#Data Engineering 実務において主流の一つであるリレーショナルデータベース管理システム MySQL :: MySQL 8.0 リファレンスマニュアル :: 1.2.1 MySQL とは
-
Kubernetes/Deployment