環境
手動リリースまたは脆弱なリリースを行うチーム。 Dockerとバージョン管理された構成。重要な依存関係とする前に、テスト、リリース、およびメンテナンスの方法を定義します。
製品のコンテキストにおける機能
この選択は、ドメイン、チーム、データ、運用、保守期間を考慮に入れたものです。
- 手動リリースまたは脆弱なリリースを行うチーム。
- 同等の環境を必要とするアプリケーション。
- 可用性と復旧に関する要件を持つサービス。
- 事象を理解するために文脈を必要とする製品。
テクノロジーを採用するということは、そのライフサイクル全体を所有することを意味する。
コンポーネントは、具体的なニーズを解決し、チームがそれをアップグレード、監視、交換できる場合に価値を生み出します。そのため、既存のアーキテクチャ、データ、および製品の実際の運用方法との適合性を評価します。
パイプライン
同等の環境を必要とするアプリケーション。 構築、テスト、分析、そしてプロモーション。重要な依存関係とする前に、テスト、リリース、保守の方法を明確に定義します。
ランタイム
可用性と復旧に関する要件を持つサービス。 Linux、Nginx/Apache、PHP-FPM。これらを重要な依存関係とする前に、テスト、リリース、メンテナンスの方法を明確に定義します。
可観測性
事象を理解するために文脈を必要とする製品。 ログ、メトリクス、トレース、アラート。これらを重要な依存関係とする前に、テスト、リリース、保守の方法を定義します。
私たちが設計、構築、運用できるもの
Dockerとバージョン管理された構成。
構築、テスト、分析、そしてプロモーション。
Linux、Nginx/Apache、およびPHP-FPM。
ログ、メトリクス、トレース、アラート。
関連技術
ドッカーGitHub ActionsGitLab CI
LinuxNginx / ApachePHP-FPM
監視ログバックアップ
ロゴでは答えられない決断
再現性を向上させる場合には有効だが、それ自体では役に立たない。
プロバイダーは、可用性と復旧設計に取って代わるものではありません。
すべてのアラートには、影響力、責任の所在、そして明確な対応策が必要です。
別の技術的な孤立領域を作り出すことなく導入する
導入は、明確な互換性、所有権、そして出口戦略を伴う、限定されたニーズから始まります。
まず、統合性、開発者エクスペリエンス、パフォーマンス、運用性を検証する代表的な事例から始めます。構成、トレーニング、導入、可観測性、バックアップ、セキュリティ、アップグレードといったコストを理解する前に、システム全体にテクノロジーを拡散させることは避けます。
導入が完了したと言えるのは、再現性のある操作方法が確立された時です。これには、最低限の運用手順、有用なテスト、診断機能、ドキュメント、そして使用するか否かを判断できる担当者の存在が含まれます。依存関係が消滅したり、ライセンスが変更されたり、あるいは適合しなくなった場合でも、製品は適切な代替手段を保持する必要があります。
- 検証する必要性、代表的な事例、そして具体的な導入範囲。
- 統合する実際のテスト、データ、セキュリティ、および運用条件に基づいて。
- 標準化するチームが利用できる規約、所有権、診断、およびメンテナンス。
- レビュー価値、コスト、サポート、代替案、および交換条件。
テクノロジーを導入する前に
技術がアーキテクチャを決定するのか？
いいえ。ドメイン、チーム、運用、そして製品の将来像によって、その使用方法は異なります。
既存のアプリケーションに組み込むことは可能ですか？
はい、統合によって実際のコストやリスクが削減され、導入および運用計画が存在する場合です。
この決定に関連するコンテンツ
診断、処置、または関連する経験を継続してください。
最初の会話
PHPアプリケーションに必要なものについて話し合いましょう
状況、主な阻害要因、そして求める結果についてお聞かせください。初期評価に必要な質問を返信いたします。
- 商業的な義務は一切ありません
- チームとの直接連絡
- お客様の個人情報は第三者に販売されることはありません。