®OTOKO® 提供的 Microsoft Azure
Microsoft Azure 应当承载您的各类应用、支持新项目的开展，并融入现有的 Microsoft 生态。仅靠订购几项单独的服务还不够。OTOKO® 将平台搭建、迁移和运维，与清晰透明的成本及合同规划结合起来：从用户权限和网络，到按您的实际用量签订消费承诺是否划算，均纳入考量。
我们为您承担的工作
由 OTOKO® 负责规划、实施与约定的运维
示意图 · 并非服务商站点实景照片您对 OTOKO® 的委托
某个业务部门急需一套新环境，而 IT 部门还在协调访问权限、网络和预算。与此同时，各类应用已经在配置各异的订阅中运行。我们正是从这里入手：盘点现状、制定统一规则，并在可靠的基础上接入下一批应用。
具体任务范围取决于您的起点：整理现有的 Azure 环境、搭建 Landing Zone，或是连同移交一并完成应用迁移。实施内容包括配置、测试和文档编制。后续的运维支持会针对系统和服务范围单独约定；采购方面的问题，我们会结合您的技术规划一并考虑。
具体服务详情服务范围
服务模块涵盖从统一的平台基础到合同审查的各个环节。起点既可以是一个新应用，也可以是一套现有的系统环境；具体顺序则取决于技术依赖关系和所需的支持范围。
新项目需要在您的 Azure 环境中拥有明确的位置。为此，我们会规划订阅结构，将测试环境与生产环境分开，并分配相应的权限和成本中心。可重复使用的配置，能帮助您的团队按照同样的规则搭建更多环境。现有资源也会一并检查，看是否能够纳入这一结构之中。
一个版本化的 Landing Zone，包含角色模型、策略规则，以及新增 Subscription 的成文流程。
Management Groups、Subscriptions 和 Resource Groups 共同构成您 Azure 环境的整体结构。我们负责界定开发与生产环境的划分，通过 Azure RBAC 设置角色，并通过 Azure Policy 制定规则。命名规范、标签和预算会与相关负责人共同商定。Terraform 或 Bicep 会以 Infrastructure as Code 的形式，落实约定好的基础架构。
用户账户、名称解析和网络路径，必须在云端与数据中心之间保持一致。我们会依据您的应用及其通信路径来规划对接方案，随后设置并测试访问权限和连接，同时明确一旦发生中断，哪些业务流程会受到影响。
一套访问与网络方案，包含成文记录的连接方式，以及对所需数据路径的测试。
身份管理和网络访问会作为一个整体加以考量：现有的 Active Directory、Microsoft Entra ID、管理角色、DNS 以及网络分段。针对与数据中心的连接，我们会评估站点到站点 VPN 或 ExpressRoute 方案。路由、名称解析和故障场景，都会在迁移之前明确。
并非所有应用都以同样的方式完成迁移。我们会与您的负责人一起检查服务器、数据库和接口，选择合适的目标环境，并将相互关联的系统归并为若干迁移波次。业务测试、协调一致的切换，以及向运维团队的移交，都属于同一个项目的组成部分。
一份工作负载评估、一套迁移规划，以及针对已迁移应用的协调一致的验收方案。
我们会评估虚拟机、数据库和接口，并规划迁移波次。Azure Migrate 可以为现状评估提供支持。针对目标蓝图，我们会结合您的应用，比较 Azure Virtual Machines、App Service 和 Azure Kubernetes Service（AKS）。业务测试和回退方案会贯穿整个切换过程。
只有当有人知道该如何应对时，告警才能真正发挥作用。针对您的 Azure 系统，我们会将监控、报告路径、备份和恢复，与实际运维需求相匹配。由此形成明确的任务分工：一部分由您的团队承担，另一部分交由我们负责的运维支持完成。
一套运维与恢复方案，包含告警路径、备份范围以及约定好的恢复测试。
Azure Monitor 和 Log Analytics 有助于持续观察您的运行环境；Microsoft Defender for Cloud 则可以提供额外的安全评估。我们会确定哪些告警需要处理、由谁负责响应，以及需要保留多长时间的记录。Azure Backup，以及必要时的 Azure Site Recovery，都会依据您应用的恢复目标进行评估。
究竟是哪个应用导致账单不断上涨？成本标签和使用数据，让支出可以归属到具体的团队和系统。在此基础上，我们会检查闲置资源、规格是否合适以及运行时长是否合理。各项调整会与负责人一起排定优先级，并根据实际用量加以验证。
一套归属清晰的成本基础，以及一份按优先级排定、明确负责人和可核实假设的行动计划。
借助成本标签、Azure Cost Management 以及技术层面的使用数据，我们会将支出归属到具体团队和应用。首先会考察资源规格调整、闲置资源和按计划开关的开发环境。只有在此基础上，我们才会评估 Reservations 或 Azure Savings Plans，以避免合约承诺固化不必要的消耗。
只有当承诺的用量与实际需求相符时，优惠的价格才真正划算。因此，我们会一并评估现有合同、预期用量以及可能适用的各类计划。我们的对比会清楚列出各项前提条件、期限和计费方式；折扣或返利则依据经过明确确认的条件加以核算。
一份清晰可循的方案对比，涵盖合约期限、承诺范围、适用资格、计费方式，以及以书面形式确认的条款。
我们会审视您现有的合同和采购渠道，例如 CSP 或与 Microsoft 直接签订的合约。Microsoft Azure Consumption Commitment（MACC）、Reservations 和 Savings Plans 是三种不同的工具。可能的折扣、激励补贴或返利，我们会依据具体计划和方案逐一核实；它们并不会仅凭一项消费承诺就自动产生。
规划与实施详解
Azure 环境会随着各业务部门的需求不断扩展。要使其成为一个协调统一的平台，架构、运维组织和采购必须统一规划。我们会与您的 IT 部门以及各应用负责人共同推进这些决策。
许多企业并非从零开始：用户账户往往早已存在，部分团队已在使用 Azure，本地应用也在访问内部目录服务或文件服务。因此，在扩展之前，我们会先梳理哪些身份、订阅（Subscription）和网络连接正在被实际使用。这里关注的不仅是配置本身，还有其形成的原因：是谁设置了某项例外，哪个应用需要它，谁有权决定是否变更？这样的盘点可以避免新的目标蓝图在不知不觉中打断正常运行的业务流程。
基于现有情况，我们会构建一套职责分工与技术边界相互匹配的结构。开发环境与生产环境将获得必要的隔离，管理任务也会分配给相应的角色。此外，我们还会共同明确：其他团队如何申请新环境，以及由谁审批成本和访问权限。首个项目的接入将作为实际检验。这样，您的团队获得的不仅是一张架构图，更是一条清晰可循的路径，能够在日常工作中使用该平台，并在日后自行继续完善。
要迁移一个应用，仅仅确定合适的虚拟机规格是不够的。还需要考虑数据库、登录方式、外部接口、后台任务，以及能否从企业网络访问。我们会共同审视哪些组件可以原封不动地迁移，哪些地方需要或应当进行调整。这一决策需要在改造工作量、运维任务和现有技能之间权衡。技术上可行的现代化改造，并不一定要成为第一波迁移的一部分。
在目标规划阶段，就会明确监控、备份和恢复的职责归属。哪些告警对运维而言是重要的？更新之后由谁来验证功能是否正常？恢复之后哪些数据必须保持一致？这些问题会被纳入测试计划和移交内容。一个具有代表性的工作负载有助于在进一步迁移之前验证相关流程。只有对技术和业务功能进行共同评估，才能判断是否已具备承载更多应用的基础。
一项合同决策所影响的成本，会持续到下一个结算月份之后。因此，我们会将现有的采购渠道和绑定期限，与平台的规划用途一并考量。项目临近结束、应用的现代化改造，或运行时段的调整，都可能显著改变实际需求。用量数据会据此加以解读，而不是简单地沿用过去的峰值负载。在基于当前用量评估长期承诺之前，应当先让技术层面的优化效果显现出来。
对比会列明期限、前提条件、结算方式，以及使用量假设的可靠性。消费承诺（Commitments）、预留实例（Reservations）和节省计划（Savings Plans）会被视为不同的选项，而不是被描述为可以互相替代的折扣承诺。对于可能的激励补贴或返利，我们只会依据具体的计划条款和已确认的报价来考量。这样一来，您的决策始终可以核查：采购部门和 IT 部门都能看到其所依据的假设、由此产生的义务，以及在做出绑定之前还应厘清哪些变化。
我们的协作方式
您无需亲自安排每一个技术环节。我们会记录任务和决策，并在需要您团队的专业知识或审批时，及时让其参与进来。
从现有的订阅、连接和合同可以看出，哪些基础已经具备。据此，我们界定后续搭建或进一步扩展的范围。
您的参与： 请说明受影响的应用、租户负责人以及计划中的变更。
我们会先在一个选定的应用上检查配置、访问权限和数据路径，待共同评估之后，再逐步扩展到其他环境。
您的参与： 您的应用团队负责检查业务流程，并批准下一步工作。
我们会移交配置和运维任务。成本中心和报告路径让运行环境的责任归属一目了然。
您的参与： 请确认负责运维、预算以及后续审批的相关人员。
示例项目场景
以下是一个可能的合作项目示例，具体范围将取决于您的实际情况。
多个团队已经在使用 Azure，但访问权限、网络连接和结算方式各自遵循不同的规则。
我们会评估现有环境，确定统一的目标架构，并分步将各个应用迁移过去。
一套责任清晰、成本一目了然的平台，让更多项目能够有计划地在其上启动。
您将获得什么
包含账户、网络和权限方案的 Azure 目标架构
包含迁移、测试和验收的实施计划
包含职责划分和成本概览的运维文档
从技术与经济角度规划 Azure
任何可能的优惠，都必须契合您的实际需求。在您做出决定之前，我们会与您一起评估采购模式、用量和绑定条款。
综合考察现有成本、预期用量和计划中的变更。
根据资格条件、合同和期限，评估合适的计划和采购模式。
在具体报价中记录折扣或返利、计费方式、义务和前提条件。
是否存在优惠、优惠幅度多少，取决于具体计划和您的报价，以其中约定的条款为准。
洽谈 Azure 合作条件从意向到具体委托
在初步沟通阶段，这些资料无需齐全。我们会共同确认现有信息，以及评估还需要补充哪些内容。
报价中会明确服务范围、您团队的参与方式、所需权限、验收标准和移交安排。服务商费用、项目服务费用与持续运维费用之间的界限也会清晰划分。
洽谈评估启动之前
我们会与您一起审视用量、现有合同、计划期限以及合适的采购模式。是否适用消费承诺、折扣或返利，取决于相应的计划、您的资格条件以及具体报价。相关条件、绑定期限和结算方式都会在做出决定前以书面形式明确。
规划 Azure、迁移应用并持续优化运维。OTOKO® 将技术实施与您的成本及采购方案审查结合在一起。
可以。我们会根据您的接口、身份管理、网络以及可用性和数据存放地点方面的要求，规划混合架构。
MACC 指的是对 Microsoft 作出的合同约定消费承诺。Reservations 针对特定的合资格资源；Savings Plan 则承诺在合资格的使用上每小时消费约定的金额。适用范围和条款会分别加以核实。这些模式都不等同于一笔固定返利。
可以。在做出任何变更之前，我们会先核查租户、身份、Subscription 和依赖关系。不过，现有的 Microsoft 365 使用情况，既不能替代 Azure 架构方案，也不能省去对所需许可证和权限的审核。
采用混合云或多云架构是可行的。在规划过程中，我们会明确设计数据流、网络连接、身份管理和职责分工。数据传输、延迟以及额外增加的运维复杂度，都是决策时需要考虑的因素。
在核实之前，无法负责任地给出固定金额。真正起决定作用的是采购模式、合资格的消耗量、合约期限以及计划规则。我们会在方案中记录已确认的优惠和相应前提条件；预计的节省金额，不会被当作有保证的结果来呈现。
OTOKO® 提供的 Microsoft Azure
请带来一个具体的项目：一次即将进行的迁移、混乱不清的订阅结构，或是下一次合同决策。我们会共同界定任务范围，并明确为了给出可靠报价，还缺少哪些现状和用量数据。
预约 Microsoft Azure 初步沟通
