Skip to main content

Paylaşılan Hizmetler (Shared Services)

Sistem Analizi

MimariPRODUCTION

Normal Davranış

Kararlı, sürüm kontrollü (versioned) dahili API'leri ve iyi tanımlanmış Hizmet Düzeyi Hedefleri (Service Level Objectives - SLOs) ile self servis (self-service) geliştirici platformlarını kullanıma sunar (exposes). Özerk (autonomous) ürün ekiplerinin (product teams), temel mimari ilkelleri (architectural primitives) ve uyumluluk kontrollerini gereksiz yere (redundantly) yeniden icat (reinventing) etmeden iş (business) uygulamalarını hızla oluşturmasına, dağıtmasına ve işletmesine olanak tanır.

Çöküş Davranışı

Paylaşılan hizmet (shared service) bir kurumsal (organizational) ve operasyonel tek arıza noktası (single point of failure) haline gelir. Sürüm kontrolü olmayan (unversioned) paylaşılan API'lere sıkı sıkıya bağlılık (tight coupling), beklenmedik kilitlenen (breaking) değişiklikler veya temel (core) bir paylaşılan platform (shared platform) bileşenindeki (component) bir kesinti anında tüm bağımlı ürün ekiplerine yayılarak dağıtımları durdurur ve birden fazla müşteriye dönük (customer-facing) uygulamayı aynı anda devre dışı bırakır.

İş Sonuçları

Paylaşılan hizmetler, ek yükü (overhead) azaltmak için birden fazla özerk ürün ekibi tarafından kullanılan merkezi platformlardır. Paylaşılan bir hizmet bir kesinti veya kaynak tükenmesi (resource exhaustion) (gürültülü komşu sorunu - noisy neighbor problem) yaşadığında etki alanı (blast radius) maksimize edilir. Paylaşılan bir kümedeki (shared cluster) tek bir ekibin bellek sızıntısı (memory leak), bir düzine diğer ekibin iş yüklerini çökertebilir, tüm mühendislik organizasyonunu felç edebilir ve birden fazla ürün hattını aynı anda durdurabilir.

Görsel Tezahür

"Slack '#engineering-general' kanalı (channel), dağıtımlarının (deployments) neden başarısız olduğunu soran altı farklı ekipten gelen kafası karışmış mühendislerle (engineers) patlar; Kubernetes gösterge panelleri (dashboards), paylaşılan küme genelinde kademeli (cascading) NodeNotReady olaylarını gösterir."

Satirical Behavior

"An organizational compromise that promises efficiency and cost savings, but actually just ensures that when one team breaks something, they have the privilege of taking the rest of the company down with them."

Bilinen İsimler

Platform TeamInternal Tooling

Teknik Terminoloji

Platform engineeringStandardizing stackDeveloper portal

Hata Göstergeleri

Platform bottleneckService unavailableDependency conflict

Sistem Mimarisi

Click or hover to interact

Kullanan Karakterler

FAQ

Normalde nasıl davranır?

Kararlı, sürüm kontrollü (versioned) dahili API'leri ve iyi tanımlanmış Hizmet Düzeyi Hedefleri (Service Level Objectives - SLOs) ile self servis (self-service) geliştirici platformlarını kullanıma sunar (exposes). Özerk (autonomous) ürün ekiplerinin (product teams), temel mimari ilkelleri (architectural primitives) ve uyumluluk kontrollerini gereksiz yere (redundantly) yeniden icat (reinventing) etmeden iş (business) uygulamalarını hızla oluşturmasına, dağıtmasına ve işletmesine olanak tanır.

Nasıl çöker?

Paylaşılan hizmet (shared service) bir kurumsal (organizational) ve operasyonel tek arıza noktası (single point of failure) haline gelir. Sürüm kontrolü olmayan (unversioned) paylaşılan API'lere sıkı sıkıya bağlılık (tight coupling), beklenmedik kilitlenen (breaking) değişiklikler veya temel (core) bir paylaşılan platform (shared platform) bileşenindeki (component) bir kesinti anında tüm bağımlı ürün ekiplerine yayılarak dağıtımları durdurur ve birden fazla müşteriye dönük (customer-facing) uygulamayı aynı anda devre dışı bırakır.

İş sonuçları nelerdir?

Paylaşılan hizmetler, ek yükü (overhead) azaltmak için birden fazla özerk ürün ekibi tarafından kullanılan merkezi platformlardır. Paylaşılan bir hizmet bir kesinti veya kaynak tükenmesi (resource exhaustion) (gürültülü komşu sorunu - noisy neighbor problem) yaşadığında etki alanı (blast radius) maksimize edilir. Paylaşılan bir kümedeki (shared cluster) tek bir ekibin bellek sızıntısı (memory leak), bir düzine diğer ekibin iş yüklerini çökertebilir, tüm mühendislik organizasyonunu felç edebilir ve birden fazla ürün hattını aynı anda durdurabilir.

How does the shared services pattern inadvertently create enterprise-wide deployment bottlenecks?

When shared services evolve into monolithic dependencies where product teams must request manual configuration changes (via ticketing queues) or when multiple teams are forced to deploy against a single shared database or staging environment, organizational velocity stalls. Independent release cadences collapse into synchronized release trains, negating the agility benefits of microservice architectures.

How can engineering platform teams enforce multi-tenant isolation and prevent noisy neighbor starvation in shared internal services?

Platform teams must implement strict per-team rate limits, concurrency controls, separate execution queues, and bulkhead resource isolation patterns across all shared APIs and worker pools. Without explicit quota enforcement and tenant-level telemetry, a single runaway script or unoptimized batch query from one team can exhaust shared database connection pools and degrade service for the entire enterprise.

Sistemi keşfet

Incidentpedia'da devam et→Olay Dizinini oku→Stack'leri incele→Konuları keşfet→Bölümleri izle→Ajanlar→

AI özeti

Shared Services is a ARCHITECTURE system in TinyCTO.tv. Exposes stable, versioned internal APIs and self-service developer platforms with well-defined Service Level Objectives (SLOs). It enables autonomous product teams to rapidly build, deploy, and operate business applications without redundantly reinventing core architectural primitives and compliance controls.