Bu konuda etiket tasarımının arka planı, ilkeleri, en iyi uygulamaları ve örnekleri açıklanmaktadır.
Arka Plan
Bir kuruluşun yalnızca birkaç cloud kaynağı varsa bunları hafızadan veya manuel kayıtlardan sınıflandırabilirsiniz. Ancak cloud kaynaklarının sayısı arttığında (büyük kuruluşlarda binlere ulaştığında) manuel sınıflandırma güvenilirliğini yitirir ve platform tabanlı bir çözüm gerekir.
Alibaba Cloud'da kaynaklarınızı işaretlemek ve sınıflandırmak için etiketleri kullanabilirsiniz. Bir kaynak oluştururken iş ve finansal sahiplik gibi özelliklerle etiketleyebilirsiniz. Örneğin kaynakları oluşturan kişiye, bölgeye veya projeye göre etiketleyebilirsiniz. Kaynakları oluşturma sırasında etiketlemezseniz bu özellikleri daha sonra düzenlemek çok daha zor olur.
Etiket Tasarımının İlkeleri
-
Karşılıklı Dışlayıcılık İlkesi
Karşılıklı dışlayıcılık ilkesi aynı kaynak niteliği için birden fazla etiket anahtarı kullanılmasını engeller. Örneğin bir kaynağın sahibini belirlemek için owner etiket anahtarını kullanıyorsanız own, belonger veya owner_cn gibi benzer anahtarlar kullanmayın.
-
Kapsamlı Tükenmişlik İlkesi
Kapsamlı tükenmişlik ilkesi tüm kaynakların planlanmış etiket anahtarlarına ve ilgili etiket değerlerine sahip olmasını gerektirir. Örneğin bir şirketin üç oyun projesi departmanı varsa ve project etiket anahtarını kullanıyorsa bu departmanları temsil eden en az üç etiket değeri bulunmalıdır.
Kapsamlı ve tükenmiş bir etiketleme ilkesi; kaynak erişimi, maliyet dağıtımı, otomatik operasyon ve bakım ile erişim kontrolü gibi etiket boyutuna dayalı operasyonlar için ön koşuldur.
-
Sınırlı Değerler İlkesi
Sınırlı değerler ilkesi bir kaynak için yalnızca temel etiket değerlerinin korunmasını ve gereksiz olanların silinmesini amaçlar. Örneğin bir şirketin beş departmanı varsa departman etiket anahtarı için yalnızca buna karşılık gelen beş etiket değeri bulunmalıdır. Bu yaklaşım yönetimi basitleştirir.
Sınırlı değerler ilkesi kaynak erişimini, maliyet dağıtımını, otomatik operasyon ve bakımı ile erişim kontrolünü kolaylaştırır.
-
Gelecekteki Değişiklikleri Dikkate Alma İlkesi
Etiketleri tasarlarken etiket değerleri eklemenin veya kaldırmanın etkilerini değerlendirerek gelecekteki değişiklikleri planlayın. İş sınırlarını net bir şekilde tanımlamak etiketlerinizi daha esnek ve değiştirilebilir hale getirir. Örneğin cloud kullanımına yeni başlayan bir kuruluş merkezi iş operasyonlarına sahip olabilir ve kaynak sahipliğini, finansal sahipliği ve otomatik operasyon ve bakımı yönetmek için department gibi tek bir etiket kullanabilir. Kuruluş büyüdükçe bu tek etiket iş mantığıyla aşırı yüklenerek ileride ayrıştırılmasını maliyetli ve zor hale getirebilir. Bu nedenle bulut benimseme sürecinin başında etiketler için iş gereksinimlerinizi değerlendirmelisiniz. Bu örnekte başlangıçtan itibaren department, costcenter ve ops etiketlerini kullanmak daha iyidir.
Etiketlerin değiştirilmesi etiket tabanlı erişim kontrolünü, otomatik operasyon ve bakımı veya ilgili fatura raporlarını etkileyebilir. Hem kurumsal hem de kişisel kullanım durumlarında kaynakları teknik, iş ve güvenlik boyutlarından yönetmek için işle ilgili etiketler oluşturmalısınız. Kaynakları ve hizmetleri yönetmek için otomatik operasyon ve bakım kullandığınızda otomasyon görevlerine yardımcı olacak ek özel etiketler tasarlamanız gerekir.
-
Basitleştirilmiş Tasarım İlkesi
Basitleştirilmiş tasarım ilkesi iş ihtiyaçlarınızı karşılayan basit anahtarlara ve değerlere sahip sabit bir etiket kümesi kullanmaktır. Örneğin proje ortamları için etiket tasarlarken test ortamları için test-environment gibi tutarlı bir etiket anahtarı kullanın. pre-test-environment veya formal-test-environment gibi birden fazla benzer anahtarı sürdürmeyin.
Bu ilke çok sayıda etiket anahtarından kaynaklanan operasyonel hataları azaltabilir.
-
Standart Adlandırma İlkesi
Standart adlandırma ilkesi farklı açık kaynak araçlarla uyumluluğu sağlamak ve gelecekteki API entegrasyonunu basitleştirmek için etiketlerde standart bir adlandırma formatı kullanmaktır. Örneğin etiket adlarında İngilizce kelimeler varsa yalnızca küçük harf kullanın.
Etiket Tasarımı İçin En İyi Uygulamalar
Bir internet şirketinin İş, Pazarlama ve Operasyon ve Bakım olmak üzere üç departmanı vardır. Her departman bir veya daha fazla projeyi yönetir. Her projenin farklı yaşam döngüsü aşamaları için üretim, geliştirme ve test ortamları bulunur. Operasyon ve Bakım ekibinin şirketin kaynaklarını gerçek zamanlı olarak izlemesi, her proje için maliyetleri periyodik olarak dağıtması, kaynak erişimini kontrol etmesi ve otomatik operasyon ve bakım uygulaması gerekir.
Şirket bu gereksinimleri karşılamak için etiketlerini aşağıdaki gibi tasarlamıştır.
|
Gereksinim |
Etiket tasarımı |
Açıklama |
|
Kaynaklara erişme ve kaynakları yönetme |
Aşağıdaki üç düzeydeki etiketleri oluşturun ve tüm kaynaklara ekleyin:
|
Kuruluşunuzun derin bir hiyerarşisi varsa şube ofis (şirket) etiketi gibi üst düzey etiketler eklemeyi düşünün. |
|
Maliyetleri ve maliyet dağıtımını yönetme |
Tüm kaynaklara bir maliyet merkezi etiketi oluşturun ve ekleyin:
|
Yok |
|
Kaynak erişim kontrolü |
Proje üyesi olmayan kişilerin ECS örnekleri gibi proje kaynaklarına erişimini kısıtlayın. |
Daha fazla bilgi için bkz. Belirtilen ECS örneklerini yönetmek için RAM kullanıcılarını etiketlerle kısıtlama. |
|
Otomatik operasyon ve bakım |
Günlük kaynak denetimleri için purpose anahtarına sahip bir amaç etiketi oluşturun. Değeri her gün saat 08:00'de otomatik denetim yapılacağını belirtmek için autocheck-8am olarak ayarlayın. Bir denetim anormallik bulursa sorumlu kişiyi bilgilendirmek için kaynak sahibi etiketi owner kullanın. |
Yok |
Etiket Tasarımı Örnekleri
Aşağıdaki tabloda yaygın boyutlar için etiket tasarımı örnekleri listelenmiştir.
|
Sınıflandırma boyutu |
Etiket anahtarı |
Etiket değeri |
|
Organizasyon yapısı |
|
İlgili adlar |
|
İş mimarisi |
|
İlgili adlar |
|
Rol mimarisi |
|
|
|
Amaç |
|
Amaç değeri |
|
Proje |
|
Doğru bilgileri sağladığınızdan emin olun. |
|
İş departmanı (maliyet dağıtımı ve iş takibi için) |
|
Gerçek değerler |
|
Finansal boyut sahibi (kaynak sahibini belirlemek için) |
owner |
Ad veya e-posta adresi |
|
Finansal boyut müşterisi (kaynak hizmetinin müşterisini belirlemek için) |
Özel veya gerçek değer |
Müşteri adı |
|
Finansal boyut projesi (kaynak tarafından desteklenen projeyi belirlemek için) |
project |
Proje adı |
|
Finansal boyut siparişi |
order |
Sipariş kategori ID'si |