Operations & delivery
Goodland Cloud
Technical overview — implementation, setup & support structure
Vietnam · Data, AI & GPU services · Customer-facing delivery model
Companion to Goodland-Cloud-Architecture-Pricing (what we build) — this document describes how we stand it up, run it, and support customers. Intended for internal teams, partners, and enterprise RFPs. Adjust names and SLAs to match executed contracts.
1. Scope & principles
- In scope: Onboarding methodology, environment strategy, handover to operations, support tiers, escalation, incident & change interfaces with customers.
- Out of scope (here): Detailed network diagrams, vendor-specific runbooks, and legal SLA text — those live in appendices per deployment.
- Principles: Single tenant isolation where contracted; infrastructure-as-code for repeatability; measurable SLAs; Vietnamese + English support paths; security and compliance checkpoints at each phase gate.
2. End-to-end implementation methodology
Typical greenfield customer journey from contract signature to steady-state support. Durations are indicative (weeks) for a mid-size SME; enterprise or regulated workloads add discovery and testing time.
Phase 0 — Kickoff & discovery (week 1–2)
- Assign Delivery Lead (technical) and Customer Success / CSM (commercial alignment).
- Workshops: data volumes, RPO/RTO, ERP/AI use cases, identity provider (IdP), IP allowlists, data residency confirmation.
- Outputs: solution checklist, migration window calendar, RACI, success criteria for go-live.
Phase 1 — Tenant & landing zone (week 2–4)
- Provision project / subscription / VPC (per platform choice) within Vietnam region; baseline networking, subnets, private endpoints.
- IAM: Customer admin roles, break-glass policy, MFA enforcement, API keys / workload identities.
- IaC: Terraform / Bicep / vendor-equivalent templates versioned in Git; peer review before apply to production.
- Outputs: tenant inventory sheet, network diagram (internal), access list for customer admins.
Phase 2 — Core data services (week 3–6)
- Enable object/file storage, backup policies, encryption (KMS/CMEK per contract), logging to immutable store.
- Configure IDS / monitoring feeds, alert routing to Goodland NOC mailbox/phone bridge, customer notification preferences.
- Outputs: backup verification job, first restore drill (sandbox), monitoring dashboard access for customer (read-only optional).
Phase 3 — Migration & cutover (week 4–8, parallel possible)
- Migration: Bulk transfer (appliance or high-bandwidth link), incremental sync, checksum validation.
- Cutover: Maintenance window, DNS/API endpoint switch, smoke tests, rollback criteria documented.
- Hypercare: 2–4 weeks elevated L2/L3 attention post go-live (included in Business+ or purchased).
Phase 4 — AI & GPU (optional, week 4–10+)
- RAG: document ingestion, embedding pipeline, vector DB sizing, ERP API read-only connectors, red-team prompts checklist.
- OCR / speech: queue sizing, PII handling, human review queues.
- GPU rental: quota approval, image catalog (CUDA drivers), autoshutdown for dev clusters, billing alerts.
Phase 5 — Steady state & handover
- Formal service handover to Operations: runbooks, on-call rotation, known issues log, support portal credentials.
- Quarterly review template (capacity, cost, incidents, roadmap) — see §7.
3. Environment & release strategy
| Environment | Purpose | Typical policy |
| Development | Customer integration testing, non-production data or masked sets | No production SLAs; may use smaller GPU SKUs |
| Staging | Change validation, DR rehearsal, UAT | Parity with prod where feasible; weekly refresh from anonymized snapshots if agreed |
| Production | Live workloads | Full monitoring, change windows, SLA clock |
Releases: Goodland platform changes flow through CI (lint, tests, security scan) → staging → approved change record → production during published maintenance windows unless emergency security patch.
4. Support organization structure
Functional model; headcount scales with customer base. Roles may be combined in early stage (e.g. L2+L3 same engineer on-call).
Customer-facing
Customer
admins / users
→
Portal / email
+ hotline
Goodland Cloud support tiers
L1
triage, known issues
L2
platform & config
L3
engineering / vendor
NOC
24/7 monitor
CSM
Business+ / Ent.
IR lead
security events
L1 — intake, categorization, password resets (where applicable), status comms.
L2 — storage/backup/AI service configuration, log analysis, vendor ticket filing.
L3 — deep defects, performance tuning, architecture changes, escalation to cloud/Dc partner.
4.1 Channels & languages
| Channel | Use | Notes |
| Support portal / ticketing | Primary; audit trail | Ticket ID, SLA timers, attachments |
| Email | Alternative intake | Auto-create ticket where integrated |
| Phone / hotline | Sev1 / outage | Business+ and Enterprise; maps to on-call |
| Chat | Growth+ during extended hours | Optional integration (e.g. Teams) for Enterprise |
Support provided in Vietnamese and English per customer preference; technical runbooks maintained in both languages for L1 scripts.
4.2 Coverage by commercial tier (indicative)
| Tier | Support window | Default channel | CSM / IR |
| Starter | Business hours (e.g. 08:00–18:00 ICT, Mon–Fri) | Portal / email | — |
| Growth | Extended (e.g. 07:00–22:00 ICT) + chat option | Portal + chat | — |
| Business | 24/7 for Sev1 platform down; business hours for Sev2–4 | All channels per contract | CSM optional |
| Enterprise | 24/7 multi-channel | Phone + portal + named CSM | Dedicated CSM; IR tabletop exercises optional |
5. Severity model & response targets
Targets are initial response (acknowledgement + triage start), not necessarily resolution. Final numbers belong in customer SLA/DPA.
| Sev | Definition (examples) | Initial response (Business) | Initial response (Enterprise) |
| 1 | Production storage/API unavailable for all users; data loss in progress | ≤ 30 min (24/7) | ≤ 15 min (24/7) |
| 2 | Major degradation; backup failing; single AZ impact with workaround | ≤ 4 business hours | ≤ 2 hours (24/7) |
| 3 | Partial issue; workaround exists; dev/test only | ≤ 1 business day | ≤ 8 hours |
| 4 | How-to, feature request, general question | ≤ 2 business days | ≤ 1 business day |
5.1 Escalation path
- L1 cannot resolve within SLA → assign L2 with full timeline and customer comms.
- L2 engages L3 / vendor / DC partner; Delivery Lead notified for Sev1–2.
- Customer escalation: CSM (if any) + Support Manager + optional executive bridge for Enterprise.
- Post-incident: Sev1–2 require RCA within agreed days (e.g. 5–10 business days) and corrective actions tracked.
6. Incident, change & maintenance
6.1 Incident management
- NOC monitors platform health; correlates IDS signals; opens internal incident when thresholds breach.
- Customer-visible incidents: status page update (Enterprise) or email blast per communication plan.
- Security incidents: IR playbook, customer notification per legal/regulatory timeline.
6.2 Change management
- Standard changes: pre-approved (e.g. certificate renewal) with automation.
- Normal changes: CAB review for production-impacting work; customer notice N business days before (per tier).
- Emergency changes: security patch; retrospective CAB within 48h.
7. Customer success & continuous improvement
- Onboarding checklist signed off by Delivery Lead and customer technical owner.
- Monthly (Growth+): usage & ticket trend summary.
- Quarterly business review (QBR) (Business+): capacity forecast, cost optimization, roadmap (AI/GPU features), training gaps.
- Training: Admin webinar, backup restore lab, AI acceptable-use & data-handling briefing for power users.
- Feedback loop: Product backlog fed from support tags and CSM notes.
8. RACI snapshot (delivery vs customer)
| Activity | Goodland | Customer |
| Tenant & network baseline | R (execute) | A (approve design), C (requirements) |
| Application / ERP configuration inside customer systems | C | R/A |
| Data migration tooling & cutover window | R | A (data owner sign-off) |
| Day-2 backup verification & restore tests | R (facilitate) | A (validate data) |
| Platform patching & infra CVEs | R/A | I |
| Customer IAM (users, MFA) | C | R/A |
R = responsible, A = accountable, C = consulted, I = informed.