google-cloud-waf-reliability
Generates reliability-focused guidance for Google Cloud workloads based on the Google Cloud Well-Architected Framework. Use to evaluate a workload, identify reliability requirements, and provide actionable recommendations for building resilient, highly available systems.
What this skill does
# Google Cloud Well-Architected Framework skill for the Reliability pillar ## Overview The Reliability pillar of the Google Cloud Well-Architected Framework provides principles and recommendations to help you design, deploy, and manage reliable, resilient, and highly available workloads in Google Cloud. A reliable system consistently performs its intended functions under defined conditions, is resilient to failures, and recovers gracefully from disruptions, thereby minimizing downtime, enhancing user experience, and ensuring data integrity. ## Core principles The recommendations in the reliability pillar of the Well-Architected Framework are aligned with the following core principles: - **Define reliability based on user-experience goals**: Measurement of reliability should reflect the actual experience of the system's users rather than merely relying on infrastructure metrics. Focus on outcomes that matter most to users. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/define-reliability-based-on-user-experience-goals - **Set realistic targets for reliability**: Determine appropriate Service Level Objectives (SLOs) that balance the cost and complexity of maximizing availability against business requirements. Utilize error budgets to manage feature velocity. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/set-targets - **Build highly available systems through resource redundancy**: Eliminate single points of failure by duplicating critical components across zones and regions to maintain operations during localized outages. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/build-highly-available-systems - **Take advantage of horizontal scalability**: Design system architectures to scale horizontally (adding more instances) to seamlessly accommodate load fluctuations and improve overall fault tolerance. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/horizontal-scalability - **Detect potential failures by using observability**: Implement thorough monitoring, logging, and alerting systems to proactively detect, diagnose, and address anomalies before they cause user-facing issues. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/observability - **Design for graceful degradation**: Architect systems to maintain critical functionality, even if at reduced performance or with limited features, when dependencies fail or the system experiences extreme stress. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/graceful-degradation - **Perform testing for recovery from failures**: Build confidence in system resilience by continuously simulating failures and verifying the effectiveness of automated and manual recovery procedures. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/perform-testing-for-recovery-from-failures - **Perform testing for recovery from data loss**: Regularly test backup and restore protocols to ensure rapid recovery from data corruption or loss, remaining within the defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/perform-testing-for-recovery-from-data-loss - **Conduct thorough postmortems**: Foster a blameless culture by investigating outages comprehensively to understand root causes, followed by implementing measures that prevent recurrence. Grounding document: https://docs.cloud.google.com/architecture/framework/reliability/conduct-postmortems ## Relevant Google Cloud products The following are _examples_ of Google Cloud products and features that are relevant to reliability: - **Compute**: Compute Engine Managed Instance Groups (MIGs), Google Kubernetes Engine (GKE), Cloud Run - **Networking**: Cloud Load Balancing, Cloud CDN, Cloud DNS - **Storage and databases**: Cloud Storage (multi-region), Cloud SQL High Availability, Spanner, Filestore, Firestore - **Operations**: Cloud Monitoring, Cloud Logging, Google Cloud Managed Service for Prometheus - **Disaster recovery**: Backup and DR Service, Filestore backups ## Workload assessment questions Ask appropriate questions to understand the reliability-related requirements and constraints of the workload and the user's organization. Choose questions from the following list: - How does your organization define and measure the reliability of your systems in relation to user experience? - How does your organization approach setting reliability targets for your services? - What is your organization's strategy for ensuring high availability through resource redundancy? - How does your organization leverage horizontal scalability to maintain performance and reliability? - How does your organization utilize observability (metrics, logs, traces) to gain insights and detect potential failures? - How does your organization manage alerting based on observability data to ensure timely responses to significant issues without causing alert fatigue? - What measures does your organization take to ensure systems can gracefully degrade during high load or partial failures? - How frequently and comprehensively does your organization test for recovery from system failures (e.g., regional failovers, release rollbacks)? - What is your organization's approach to testing for recovery from data loss? - How does your organization conduct and utilize postmortems after incidents? ## Validation checklist Use the following checklist to evaluate the architecture's alignment with reliability recommendations: - User-focused SLIs and SLOs are explicitly defined and actively monitored. - The architecture avoids single points of failure through cross-zone or cross-region redundancy. - Autoscaling is enabled to handle variable demand without manual intervention. - Application and infrastructure health checks are configured to trigger automated failovers. - Regular backup schedules are in place, and restoration processes are routinely tested. - The system architecture incorporates patterns like circuit breakers, retries with exponential backoff, and rate limiting to support graceful degradation. - Game days or chaos engineering practices are regularly held to validate failure recovery. - A formalized, blameless postmortem process exists to ensure organizational learning from operational incidents.
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.