[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Best practices for labels\n\nThis document provides guidance on how to design an effective label\nstrategy for your organization. Before you start creating labels, here are some\ngeneral principles you can use when you organize your Google Cloud resources using labels.\n\nGeneral principles for labels\n-----------------------------\n\n### Always use labels\n\nAlthough labels aren't mandatory, they are helpful in organizing and managing your\nGoogle Cloud resources. Labels can be used to track costs and identify resources.\nWhen you use labels for your resources, remember to follow strict\nlabeling guidelines. We recommend that you create a formal labeling policy that\naligns with key stakeholders in the organization. The [example table](#example_labels_table)\nshows what an organization-wide labeling policy looks like.\n\n### Apply labels programmatically for consistency\n\nWhen possible, apply labels programmatically. Tools such as Script and Terraform enable you to automate the label creation process and help enforce the labeling policy. These tools ensure that labels are applied consistently across all your resources. Use a case-sensitive format for labeling and apply it consistently across all resources.\n\n### Standardize labels\n\nUse a consistent and standard set of labels for all your resources. This makes it\neasier to search, filter, and manage your resources. To simplify your label\nstrategy try not to use more than ten labels. Align your labels based on how you\nwant to report costs. Consider using a standard set of label keys and values that\nwork best for your organization. Your labels can cover business use cases such as\nenvironment, data-classification, cost-center, team, component, application, and compliance.\n\nNote that standardizing on and adhering to a labeling policy is crucial for\ncentrally-managed labels. Product teams and departments can also add custom\nlabels to resources to share team-specific information. For more information,\nsee [Apply non-standard labels](#nonstandardlabels).\n\nHere's an example of how you can define a standard set of values for each of the keys:\n\n- Environment: `prod/dev/staging`\n- Data-classification: `public/internal-only/confidential/restricted/na`\n- Cost center: `c23543`\n- Team: `shopping-cart`\n- Component: `frontend/cache/backend/database`\n- Application: `shopping-cart-payments`\n- Compliance: `pci-hippa`\n\n### Avoid confidential information\n\nProtecting personally identifiable information (PII) is critical for security.\nAvoid storing PII or other confidential information in your labels.\n\n### Apply non-standard labels\n\nAlthough adhering to a label policy is crucial, labels can also be used to share\ninformation that is specific to a product team or department. In such a scenario,\nproviding resource owners of individual teams the option to apply non-standard labels\nfor each resource can help provide more context about the resource. This makes\nit easier to search, filter, and share information specific to these product teams\nor departments. For example, a single resource can have a set of\nstandard labels such as `environment:prod`, `data-classification:restricted`,\n`cost-center:c23543`, `team:shopping-cart`, `app:shopping-cart-payments`,\n`component:database`, `compliance: pci`. The resource owner can add non-standard\nlabels such as `version:5.0.1` and `replica:primary` to indicate the version\nof the database cluster and the node's replication status.\n\n### Consider change implications\n\nYour labeling strategy is likely to change in times of evolving business requirements.\nBe aware of the implications that these changes may have. For example, the addition of\nnew cost centers, microservices, or new tools can impact your labeling strategy.\n\nLabel naming scheme and pattern\n-------------------------------\n\nEvery organization has its own way of organizing resources. You can use labels to\ncategorize the resources in your hierarchy in multiple ways, helping users to filter\nfor the resources they need. When defining your label naming scheme, consider the following:\n\n- Environment, cost center, team, component, applications, compliance, and ownership associated with the resource.\n- Data classification of any data stored in the system. This is only applicable to stateful systems.\n- Labels that need to be applied at the specific resource level like Compute Engine, Cloud Storage bucket or at the project.\n- Flexibility to use optional labels, as needed, to provide more information on resources.\n\nLabel encoding and supported characters\n---------------------------------------\n\nAll key and value characters must use UTF-8 encoding. International characters\nare allowed. Keys must start with a lowercase letter or international character.\nKeys and values can contain only lowercase letters, numeric characters,\nunderscores, and dashes.\n\nExample of defining labels\n--------------------------\n\nTo define labels, here are some attributes that you need to keep in mind.\n\nIn the following label example, *altostrat* corresponds to the name of the enterprise."]]
