g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Organizasyon teknoloji tükettiğinde ne yapmalı? Organizasyon yapınızı 90 derece döndürün!

Yazar Yang Bo

Düzenle Xiaozhi

Yazar, kısa süre önce kurumsal dijitalleşme ve mimari dönüşümü düşündükten sonra üç makale yazdı. Bu ikincisi. Konu organizasyonel yapı dönüşümü üzerine odaklanıyor. Bir önceki makale "Bir Kuruluşun Organizasyon Yapısı Teknik Mimariyi Nasıl Etkiler?" ", tema arka plan bağlamının (arka plan) oluşturulmasıdır, sonuncusu" Toplu Üretim Mikro Hizmetleri için Anahtar Destekleyici Teknolojiler "olarak adlandırılır. Tema, mikro hizmet mimarisi ve DevOps anahtar destek teknolojileri hakkındadır. Okuyucular, InfoQ resmi hesabını takip edebilir ve sonraki güncellemeleri bekleyebilir.

1. İdeal ve gerçek

2016 DevOps Geliştirme Raporuna göre: Verimli kuruluşların yayınlanma sıklığı, verimsiz kuruluşlara göre 200 kat daha yüksek, teslimat döngüsü 2555 kat daha hızlı, hata kurtarma süresi 24 kat daha hızlı ve değişim başarısızlık oranı 3 kat daha düşük.

DevOps geliştirme raporu cesaret vericidir, ancak idealler dolu ve gerçek bel kemiğidir.Çoğu (özellikle büyüyen) teknoloji kuruluşlarının mevcut durumu endişe vericidir.Sadece teslim yetenekleri yüksek performanslı kuruluşların seviyesinin çok altında değildir, Ama aynı zamanda çeşitli zorluklarda:

İyileştirmek için Çok Meşgul

Kuruluşlarda "İyileştirmek için çok meşgul" şeklinde aşağı doğru bir sarmal yaygındır. Aşağıdakiler yaygın senaryolardır:

İşler bunalmış durumda
Sistem bağlantısının ağır tarihsel yükü
Eski sistemin güncellenmesi gerekiyor (tekerlekleri değiştirin)
Mühendislerin kalitesi değişir
Bilgisayar odasının kapasitesi yeterli değil ve bilgisayar odasının taşınması gerekiyor
Birlikte birçok şey kaçınılmaz olarak başarısız olacak
Patron bir arızaya meydan okuduğunda, daha çok deneme yanılmadan korkarım

Silo İkilemi

Ahırlara Çin'de bacalar veya şaftlar da denir.Genellikle tamamen işlevsel organizasyonlarda görünürler.Fonksiyonel ekipler arasındaki yetersiz güven ve zayıf işbirliği nedeniyle sürekli sürtüşmelerle kendini gösterir.Her işlevsel ekip sağlam bir ahır gibidir. isim. Aşağıdaki tipik bir senaryodur:

İş Lideri: Büyümemiz çok yavaş, neden rakiplerimizden daha hızlı ürün lansmanı yapamıyoruz?
Ürün yönetimi: Teknik ekip güçlü değil, büyük miktarda talep teşvik edilemez ve teknik sorunlar bize suçlanamaz!
Ar-Ge ekibi: Projeyi zamanında teslim etmediğimiz için bizi suçlayamayız.İhtiyaç duyduğumuz makine çalışması ve bakımı gecikti ve yerinde değil.İşletme ve bakımın patronu değiştirilmeli!
Operasyon ve bakım ekibi: Müşteriler neredeyse çıldırmış durumda.Sistemin istikrarını sağlamak için zamanımızın çoğunu ateşle savaşarak geçiriyoruz. Artık bize bir şey atmayın. Ekibim neredeyse gitti ...

Gölge BT ve "ahır tarzı" sistem yapısı

Ar-Ge, iş ekibinin teslimat gereksinimlerini karşılayacak kadar güçlü olmadığında, iş ekibi bağımsız bir Ar-Ge ekibi kurma eğilimindedir ve hatta bazıları yeniden başlayıp bağımsız bir teknoloji ve hatta bir işletim ve bakım sistemi kuracaktır. İlgili ekip normal Ar-Ge'den ayrı olduğundan ve doğrudan iş koluna rapor verdiğinden gölge BT olarak da adlandırılır. Gölge BT, bir "ahırı" yeniden inşa etmeye eşdeğerdir ve kuruluşa verilen "hasar" şunları içerir:

Tekrarlanan fonksiyon yapısı ve bakımının neden olduğu tekrarlanan yatırım
"Ahır" sistemleri arasındaki etkileşimlerin entegrasyonu ve işbirliği maliyetlidir
İşletmenin yağış ve sürdürülebilir gelişimine elverişli değil

Alibaba'nın geliştirilmesinin ilk günlerinde, birçok "ahır" tarzı sistem inşaatı yapıldı, ayrıntılar için eke bakın.

Gölge BT'nin yalnızca dezavantajları olmadığını, aynı zamanda beklenmedik rekabetçi teşvikler ve yenilikler getirebileceğini unutmayın.

Proje sisteminin dezavantajları

Şu anda, çoğu Ar-Ge kuruluşu hala geleneksel proje tabanlı Ar-Ge modelini benimsiyor. Ar-Ge personeli projeyi takip ediyor. Bir proje henüz tamamlandı ve yakında yeniden başlatılması için yeni bir projeye atanacak. Birkaç projeden sonra Ar-Ge personelinin proje tecrübesi artacaktır ancak genellikle ürün sahipliği (sahiplik) duygusu yoktur ve iş alanında bilgi birikimi oluşturamazlar, basitçe söylemek gerekirse, bu iş değildir. Uzun vadede, Ar-Ge personelinin coşkusunun ve yaratıcılığının azalmasına, sık sık iş atlamasına ve düşük istikrara neden olacaktır. Çoğu danışmanlık ve dış kaynak şirketi proje tabanlıdır ve benzer sorunlar özellikle açıktır.

Teknoloji odaklı ve iş odaklı tuzaklar

Çoğu teknik kuruluş, teknoloji odaklı olduklarını iddia eder, ancak iş ve teknolojinin birbirinden ayrıldığı işlevsel organizasyonlarda gerçek durum, teknik departmanın hiç yönlendirilmemesi, en fazla destek olması ve bazılarının genellikle desteklenmesi. Roller. Nedeni basit. Bir yandan, iş tarafı tahtada konuşma ve kek çizmede teknik tarafa göre kesinlikle daha iyidir ve patronun onayını almak daha kolaydır; diğer yandan, teslimat verimliliği ve sistem istikrarı nihai olarak aşağı akış teknik tarafına bağlıdır. Bunlar Patron, bir sorun olduğunda, iş tarafının yukarı akıştan dikkatini dağıtmanın daha kolay olduğunu ve doğal olarak geride olanın aşağı akış teknik tarafı olduğunu doğrudan algılayabilir. Teknik tarafın genellikle fazla mesai konusunda hiçbir şikayeti yoktur, ancak sıranın takımda olduğunu söylemek zor.

Geliştirme ve operasyonlar arasındaki gerilim

Geliştirme, operasyon ve bakımın birbirinden ayrıldığı katı işlevsel bir organizasyonda, her iki tarafın da KPI hedefleri genellikle tutarsız ve hatta çelişkilidir:

Geliştirme, yeni işlevlerin ve değişikliklerin daha fazla ve daha hızlı sunulmasını gerektirir;
İşletme ve bakım, mevcut sistemi değiştirmeden mümkün olduğu kadar stabilitesini sağlamalıdır.

Hedef çatışması, iki taraf arasında doğal bir gerilim yaratır.

2. İlke

Sistem Kontrolünün Prensipleri

W. Edwards Deming, bir sistem performansını belirleyenin sistemde çalışan insanlar değil, sistem olduğunu belirtti.Sistemin performansı, sistemde çalışan kişiler tarafından değil, esas olarak sistemin kendisi tarafından belirlenir.

Deming, belirli bir bağlamda (sistem organizasyonu), bireylerin genellikle ellerinden gelenin en iyisini yapmak için ellerinden gelenin en iyisini yapmak için kendilerini motive ettiklerine inanır. Bununla birlikte, sistemin kendisinde bir sorun varsa, bireylerin sistem içindeki performansını büyük ölçüde kısıtlayacaktır. Bu nedenle, yukarıda bahsedilen ikilem ışığında, basitçe sistemdeki bireyleri suçlayamayız, temel bir çözüm bulmak için sistem organizasyonunun enlemine göre düşünmeli ve ayarlamalıyız.

Conway Hukuku

Melvin Conway, 1967'de sözde Conway Yasasını önerdi ve organizasyon yapısı ile sistem mimarisi arasında örtük bir haritalama ilişkisi olduğuna dikkat çekti:

Sistemi tasarlayan organizasyon, bu organizasyonların iletişim yapılarının kopyaları olan tasarımları üretmekle sınırlıdır.Sistemi tasarlayan organizasyon, bu organizasyonların iletişim yapılarının kopyaları olan tasarımları üretmekle sınırlıdır.

Conway yasasının aydınlanması: Yazılım sisteminin arayüz yapısı, organizasyonun iletişim yapısını yansıtacaktır Organizasyon yapısı mantıksız ise, verimli bir sistem mimarisi kurmak imkansızdır. Genel olarak, sistem mimarisi ayarlandığında, ilgili organizasyon yapısının ayarlanması, iki tarafın bir etki yaratmak için etkileşime girebilmesi için önceden düşünülmelidir. Ayrıntılar için bakın. Conway Yasası, son yıllardaki popüler mikro hizmet mimarisinin arkasındaki örgütsel ilkedir.

DevOps ilkesi

En çok satan BT operasyon ve bakım yönetimi kitabı "Project Phoenix" in yazarı Gene Kim, birçok yüksek performanslı BT organizasyonunu araştırdıktan sonra, DevOps işlemlerini destekleyen üç ilkeyi (The Three Ways: The Principles Underpinning DevOps) aşağıdaki şekilde gösterildiği gibi özetledi:

İlke 1: Sistem Düşüncesi

Yeteneği yazılım üretme değil, sürekli olarak müşteri değeri sunma olan geliştirme odaklı kuruluşlar. Değer, iş gereksinimlerinden başlar, Ar-Ge ve testlerden, dağıtım, çalıştırma ve bakıma kadar gider, sırayla akar ve nihayet müşterilere hizmetler şeklinde sunulur. Tüm değer zincirinin akış hızı, tek bir parçanın (ekip veya bireyin) olağanüstü çalışmasına bağlı değildir, ancak tüm değer zincirinin en zayıf halkası (darboğaz) ile sınırlıdır. Bu nedenle, yerel optimizasyon genellikle etkisizdir, ancak küresel hasara neden olur.

Gene Kim özellikle şunları söyledi: Darboğaz dışında herhangi bir yerde yapılan herhangi bir iyileştirme bir illüzyondur. Darboğazın ötesinde herhangi bir optimizasyon iyileştirmesi sadece bir yanılsamadır.

Sistem düşüncesi, ekip çalışmasını güçlendirmemizi, akış düşüncesini geliştirmemizi ve darboğaz kısıtlamaları konusunda farkındalık geliştirmemizi ve darboğazları bulmaya ve hedeflenen optimizasyonlar yapmaya öncelik vermemizi gerektirir.

İlke 2: Geri bildirim döngüsünü güçlendirin (Geri Bildirim Döngülerini Güçlendirin)

Süreç iyileştirme genellikle geri bildirim döngüsünün güçlendirilmesiyle elde edilir. İkinci ilke, işletme ile müşteri arasındaki, organizasyon ekibi arasındaki, süreç ve sistem içindeki geribildirim döngüsünü vurgular. Ölçüm olmadan iyileştirme olmaz, geribildirim ölçüm verilerine dayanmalı ve veri optimizasyonu yoluyla sistem iyileştirilmelidir.

İlke 3: Sürekli Deneyim ve Öğrenme Kültürü (Sürekli Deneyim ve Öğrenme Kültürü)

Kurumsal yönetim kültürü düzeyinde, deneme yanılma, sürekli deneme, öğrenme ve iyileştirme kültürünü vurgular.

Üç, organizasyon yapısı dönüşümü

Geleneksel işlevsel organizasyon ve modern işlevler arası mikro hizmet organizasyonu

Adrian Cockcorft eski bir Netflix bulut mimarıdır.Netflix'in büyük ölçekli mikro hizmet mimarisinin başarılı uygulamasını deneyimledikten sonra, modern kuruluşların ahır tarzı işlevsel engelleri aşması ve mikro hizmet tabanlı çapraz işlevli ürün ekibi organizasyon modelini benimsemesi gerektiğini öne sürdü.

Şu anda, çoğu Ar-Ge kuruluşu, aşağıdaki şekilde gösterildiği gibi, işlevler arasında çok az örtüşme ile işlevlerini hâlâ kesin bir şekilde bölmektedir. Standart Ar-Ge süreci, ürün yöneticisi ve Ar-Ge ekibinin (kullanıcı deneyimi ekibi dahil) tekrar tekrar yeni özellik gereksinimlerini tartışmasıyla başlar; Ar-Ge ekibi yeni özelliği kodla uygular; daha sonra kod, her iki tarafı da içeren test için kalite güvence ekibine gönderilir. Testi geçtikten sonra, DBA ve O&M'yi çevrimiçi olması için gönderin; bu, DBA, sistem, ağ ve depolama yöneticileriyle (genellikle iş emri sistemi aracılığıyla) birden çok etkileşimi içerir. Tüm süreç yavaş ve çeşitli toplantı koordinasyon masraflarıyla dolu.

Bazı kuruluşlar, aşağıdaki şekilde gösterildiği gibi, uçtan uca işlevler arası bir ürün Ar-Ge ekibi organize edeceklerdir Bu organizasyon modeli, ekip içinde kapalı bir geri bildirim döngüsü oluşturabilir ve etkileşim ve iletişim maliyetini azaltabilir. Ancak, Conway yasasına göre sistem mimarisi hala yekpare ise, organizasyon yapısı ve sistem mimarisi eşleşmiyorsa, monolitik teslimat modelinde olması gereken ekipler arası işbirliğine dayalı iletişimden (çoklu ekip koordinasyonu entegrasyon regresyon testi gibi) ve teslim edilebilir teslimattan kaçınmak imkansızdır. (aktarmalar) Genel verimlilik hala sınırlıdır ve gerçek çeviklik elde edilemez.

Conway yasası bize bir yazılım sisteminin arayüz yapısının kuruluşun sosyal yapısını yansıtacağını söyler. Bu nedenle, bir kuruluş gerçekten bir mikro hizmet mimarisine dönüşecekse, ekipleri mikro hizmet ürünleri etrafında organize etmeli ve DevOps modeline göre çalışmalıdır. Ürün yöneticisi, kullanıcı deneyimi yöneticisi ve Ar-Ge yöneticisi gibi bağımsız işlevsel roller, artık kuruluşta montaj hattı şeklinde kurulmuyor. Her bir çekirdek ürünün (mikro hizmet olarak uygulanan), ekibin yönetiminden ve denetiminden sorumlu olan ve ayrıca konseptten piyasaya sürüme kadar mikro hizmet yazılımı geliştirme ve teslimatının tüm yönlerinden sorumlu bir yöneticisi vardır. Kuruluşta artık bağımsız operasyon ve bakım ekipleri ve işlevsel alt bölümler yoktur. Yalnızca altyapı ürünlerinden (IaaS / PaaS) sorumlu platform ekibi, her ürün ekibi tarafından mikro hizmetlerin sürekli olarak sunulmasını desteklemek için otomatik ve self servis platform UI Portalı veya API sağlar.

Aşağıdaki şekilden, modern çapraz işlevli mikro hizmet organizasyonunun geleneksel katı işlevsel organizasyonu 90 derece döndürmeye eşdeğer olduğunu görebiliriz. DevOps hareketi ve mikro hizmet mimarisi, tamamen teknik bir sorun olmaktan ziyade, esasen organizasyon yapısının yeniden yapılanmasıdır (Re-Org).

Geleneksel proje organizasyonu ile modern ürün platformu organizasyonu

ThoughtWorks tarafından önerilen BT liderliğinin en çok satan kitabı "Yalın Kuruluş: Yüksek Performanslı Kuruluşlar Ölçekte Nasıl Yenilik Yapar?" Adlı kitabında yazar, geleneksel katı işlevsel ve proje tabanlı kuruluşların eksikliklerine dikkat çekti ve modern ürün platformu tabanlı kuruluşlara dönüştürmek için yüksek performanslı kuruluşlardan bir şeyler öğrenmeyi önerdi. .

Aşağıdaki şekil geleneksel bir katı işlevsel ve proje tabanlı organizasyonu göstermektedir.Tipik işlevler iş tarafı, Ar-Ge ekibi ve operasyon ve bakım ekibi olarak ayrılmıştır.

Bu organizasyon modelinin dezavantajları şunları içerir:

Çeşitli işlevsel ekipler arasında ahır ikilemlerinin ortaya çıkması kolaydır

İş tarafı ve Ar-Ge ekibi güvensizse, üretmek kolaydır

Gölge BT ve ahır tarzı tekrarlayan sistem yapısı
İş odaklı ve teknoloji odaklı tuzaklar

Saf proje sürüşüne neden olmak kolaydır:

Ar-Ge personeli iş alanında bilgi birikimine sahip değil ve ekip istikrarı zayıf
Ar-Ge ve işletme ve bakım sadece proje alma ve yapma ile ilgilenir.Projenin çoklu çıktısı çoğunlukla KPI'dır.Projenin iş değerine odaklanmaz ve ürünleştirme fikirleri ve yağış yoktur.Bu, teknik sistemin uzun vadeli düzensizliğine ve sistem bağlantısının ağır tarihsel yüküne neden olmuştur. Zayıf kararlılık ve düşük teslimat verimliliği

Ar-Ge ile işletme ve bakım hedeflerinin tutarsızlığı doğal bir gerilim yaratır (daha hızlı aramak yerine istikrar aramak)

Aşağıdaki şekil, çoğu yüksek performanslı kuruluş tarafından benimsenen modern bir ürün platformu kuruluşudur. Genel fikir karmaşık değildir:

İş ve ürün araştırma ve geliştirme kapalı döngülerdir ve çapraz işlevli teslimat ekipleri mikro hizmet ürünleri etrafında organize edilir
Platform ekibi ve işletim ve bakım, Ar-Ge, işletim ve bakım çalışmalarını yürütmek ve dahili müşteriler için standartlaştırılmış platform hizmetleri sağlamak için IaaS / PaaS altyapı ürünleri etrafında çalışır.
Kurumsal ürün ekibi, müşterilere self servis bir şekilde sürekli olarak değer sunmak için standart IaaS / PaaS platformunu kullanır

Bu organizasyon modelinin avantajları şunları içerir:

Ekibi ana iş ve teknik ürünler etrafında organize edin, ekip içinde kapalı bir döngü oluşturun, ahır bariyerini kırın

Ekipler mikro hizmetler şeklinde organize edilir.Her ekip kendi mikro hizmetlerini birbirine müdahale etmeden bağımsız olarak geliştirebilir, test edebilir, yayınlayabilir ve yineleyebilir, iletişim ve koordinasyon maliyetleri düşüktür. Mikro hizmet mimarisi, kuruluşun işinin sürekli yinelemeli gelişimine yardımcı olan evrimsel bir mimaridir.

Temel iş hizmetleri ve teknik altyapı (IaaS / PaaS) standartlaştırılmış ve sistematik ürünler oluşturabilir, bunlar kuruluşta varlıklar olarak biriktirilebilir, bu da organizasyonel yeniden kullanımı, entegrasyonu ve büyük ölçekli inovasyonu kolaylaştırır.

Tüm işletme, Ar-Ge, operasyon ve bakım, birleşik bir hedefle ürünler etrafında çalışır.Herkes ürün güdümlüdür, farklı müşterilere dahili ve harici olarak hizmet verir, teknoloji odaklı ve iş odaklı tuzaktan kaçınır ve Ar-Ge ile operasyon ve bakım arasındaki gerilimden kaçınır.

Ar-Ge personeli, iş alanında kolaylıkla bilgi biriktirebilir, alan uzmanı olabilir, iş değerine daha fazla önem verebilir, kuruluşun iş yönünün formülasyonuna aktif olarak katılabilir ve organizasyonel yeteneklerin istikrarını koruyabilir.

Dört, örgütsel durum

Netflix'in BusDevOps organizasyon yapısı

Netflix, teknolojik olarak güçlü bir İnternet şirketidir, ancak teknik bir CTO pozisyonuna sahip değildir. Ürün ekibi ve teknik ekibin (UI ön uç mühendislik ekibi, Discovery arama mühendisliği ekibi ve Platform platformu ekibi vb. Dahil) tümü, ana ürün CPO'sunu bildirmektedir. Ürün sürücüsü, Şirketin temel kültürel unsurlarından biri olan Netflix, onu BusDevOps organizasyon yapısı olarak adlandırıyor.

Netflix'in bulut platformu mühendislik ekibi temel olarak temel hizmet PaaS platformunun yapımından, işletilmesinden ve bakımından sorumludur ve standartlaştırılmış platform hizmetlerini çeşitli iş kollarına eşit şekilde aktarır ve tüm kuruluşu DevOps modeline dayalı mikro hizmetlerin sürekli teslimini ve inovasyonunu gerçekleştirmesi için güçlendirir. Bu ekip, geleneksel operasyon ve bakım ekibinden farklıdır ve hibrit kapalı döngü bir mimari, çerçeve ara katman yazılımı, bulut platformu, sürekli teslimat, güvenilirlik ve performans mühendisliği, temel saha hizmetleri ve büyük veri hizmetleri ekibidir.

PaaS, bulut platformu mühendislik ekibinin temel ürün çıktısıdır. Netflix'in uygulama hizmetlerini yukarı doğru desteklemek için bir kez daha AWS IaaS'ye dayalı soyut bir pakettir. PaaS platformu, Netflix'in temel teknik servis yeteneklerinin bir çökeltilmesidir. Temel bileşenlerin çoğu, NetflixOSS adı verilen ürünleştirilmiş ve açık kaynaklıdır, ayrıntılar için bkz.

Alibaba'nın Çin-Tayvan Stratejisi

2015'in sonunda Alibaba Group, DT dönemiyle uyumlu olarak daha esnek ve yenilikçi bir "büyük orta istasyon ve küçük ön büro" organizasyon mekanizması ve iş mekanizması inşa etmek için 2018 Çin-Tayvan stratejisinin lansmanını duyurdu: ön cephe işleri daha çevik olacak ve hızlı değişikliklere daha hızlı adapte olacak. Pazar; Zhongtai, ön uç iş için güçlü destek oluşturmak için tüm grubun operasyonel veri yeteneklerini ve ürün teknik yeteneklerini entegre edecek.

Alibaba'nın stratejik yapısı "büyük ve orta platform, küçük ön büro", aşağıdan yukarıya aşağıdaki gibi dört soyut seviyeye ayrılmıştır:

İlk katman (alt katman), bilgi işlem, ağ, depolama, izleme, yayınlama, bilgisayar odası ve veri merkezi altyapısından sorumlu altyapı hizmeti IaaS (Hizmet Olarak Altyapı) katmanıdır.
İkinci katman, ara katman yazılımlarından, büyük veri temel hizmetlerinden ve Ar-Ge araç zincirlerinden sorumlu olan PaaS (Hizmet Olarak Teknik Platform) katmanıdır. İlk + ikinci katman topluca Ali sisteminde teknik orta istasyon olarak adlandırılır.
Üçüncü katman, Ali tarafından uzun yıllar süren AR-GE ve operasyon için geliştirilen temel iş yeteneği modülü (kullanıcılar, ürünler, mağazalar, pazarlama vb. Dahil) olan paylaşılan hizmet katmanıdır.Üst düzey çağrı ve entegrasyon için soyutlanmış ve bir kamu hizmeti API'sine dahil edilmiştir. Bu katmana iş merkezi de denir.
Dördüncü katman (en üst katman), farklı iş kollarına (Taobao, Tmall, Juhuasuan, vb.) Göre bölünen ve ardından farklı kullanıcı deneyimlerine göre (PC, kablosuz, üçüncü taraf erişimi) farklı sunum katmanları oluşturan ön büro iş katmanıdır. .

Genel olarak, Alinin "büyük ve orta kademe, küçük ön bürosu" şunları yansıtır:

Temel iş alanları ve teknoloji platformları, Çin ve Tayvan için hizmet ürünleri olarak belirlendi
Orta ve Tayvan ürünleriyle ilgili mikro hizmetlere dayalı çapraz işlevli bir teslimat ekibi oluşturun
Hızlı yinelemeli evrimi ve ön uç işletmelerin büyük ölçekli inovasyonunu desteklemek için Zhongtai ürünlerinin yapımını güçlendirin. Zhongtai, iş inovasyonu ekolojisini yetiştirmek ve kuluçkaya yatırmak için toprak gibidir. Toprak ne kadar verimli ve kalınsa, üzerindeki işletme ekolojisi o kadar müreffeh olur.

Beş, daha geniş bir perspektif

Yukarıda birçok organizasyon yapısı sorunu ve ilgili ayarlama stratejileri tartışılmıştır. Nihai hedef, organizasyonel çeviklik yoluyla iş çevikliğini sağlamak ve değişen pazar taleplerine hızlı bir şekilde yanıt vermektir. Organizasyon çevikliği ayrıca şunlara da bağlıdır:

Esnek mimari

Bir yandan, Conway yasasına göre, yalnızca merkezi olmayan ve modüler bir sistem mimarisi, gevşek bağlı ve oldukça esnek bir organizasyon yapısını destekleyebilir;
Öte yandan, modüler bir sistem mimarisi, çeşitli atomik işletme yeteneklerinin farklı iş modellerinde esnek kombinasyonunu destekleyebilir ve iş sınırlarını ve olanaklarını genişletebilir.

Lider teknoloji: Esnek mimari, önde gelen teknik yeteneklere dayanır PaaS bulut platformu, sürekli teslim hattı, otomasyon, izleme ve ölçüm ve diğer temel teknik yetenekler, mikro hizmet mimarisi için ön şartlardır.
Süreç garantisi: Ar-Ge kuruluşlarının teslim kabiliyeti, kuruluş içindeki Değer Akışının müşterilere akış hızına bağlıdır.Değer akışının hızı, işletme ile müşteri, organizasyon ekibi, süreç ve sistemdeki çeşitli bağlantılar arasındaki kapalı döngü geribildirim ve geri bildirimlere bağlıdır. geliştirmeye devam et. Akış hızı ne kadar hızlı olursa, teslimat kapasitesi o kadar güçlü, müşteriye daha zamanında yanıt, deneyim o kadar iyi ve ilgili müşterilerin işletmeye geri dönüşü o kadar fazla olur. Erdemli ve sağlıklı bir döngü, kurumsal iş dünyasının sürekli gelişimini teşvik edebilir. Değer akışı görselleştirme aracı çok kullanışlıdır. Kuruluşların darboğazları bulmalarına ve değer akışını hızlandırmalarına yardımcı olabilir.
Yetenek ve kültür: İster organizasyonel süreç ister teknik mimari olsun, yetenek yoğunluğundan koparsanız gökyüzünde bir kale olacaksınız. İyi bir şirket kültürü, olağanüstü yetenekleri çekebilir ve toplayabilir ve yetenekler ve kültür, her zaman yeşil olan girişimin temelidir.

6. Sonuç

DevOps2016 raporuna göre, yüksek verimli kuruluşların ve düşük verimli kuruluşların üretkenliği, büyüklük sırasına göre farklılık göstermektedir. Şu anda, çoğu teknik kuruluş hala çeşitli çıkmazlar içinde sıkışmış durumda.

Netflix ve Alibaba gibi yüksek performanslı kuruluşların birinci basamak uygulamaları, DevOps ve mikro hizmet mimarisinin teknoloji kuruluşlarının ikilemleri aşması, dönüşümü ve yükseltmesi için en iyi uygulamalar olduğunu gösteriyor. DevOps ve mikro hizmet dönüşümü esasen bir tür örgütsel yeniden yapılanmadır (Re-Org): teknik organizasyon, yarı işlevsel ve yarı matris bir organizasyondan pazar odaklı çapraz fonksiyonlu bir ortak çalışma organizasyonuna 90 derece döndürülür, organizasyon mikro hizmet ürünleri etrafında döner Bir ekip oluşturun ve Ar-Ge operasyonları gerçekleştirin. Kuruluşun iç ekibi kapalı bir döngüye ulaşır, kuruluş ve pazar kapalı bir döngü oluşturur ve pazar taleplerine daha hızlı ve daha esnek yanıt verir.

Kurumsal yapı, süreç, yetenek yoğunluğu ve kültür gibi teknik olmayan faktörler, kurumsal DevOps ve mikro hizmet mimarisi dönüşümünün başarısı veya başarısızlığı için kritiktir.

Ürün ve teknoloji birbirinden basit bir şekilde ayrılamaz Ürün odaklı bir organizasyonda, teknoloji odaklı veya iş odaklı yoktur ve proje odaklı yoktur, yalnızca ürün ve müşteri (harici ve dahili) sürücü yoktur. İnternetin bugünkü gelişmesiyle birlikte, toplum, endüstri, ürünler ve teknoloji uzun zamandır birbirinden ayrılamaz ve herhangi bir yenilik temelde entegre bir şekilde desteklenir. "İş formülasyon ihtiyaçları ve teknik ekipler bunları yapmaktan sorumludur" Parti A ve Parti B modeli, geriye dönük kavramlardır ve eksiktir. Bu zorlukların biliş ve dar görüşlü standardizm tarafından yenilip yenilemeyeceği, İnternet şirketleri için bir dönüm noktası haline gelecektir.

Not,

Bu makale yazarın kişisel çalışmalarının ve düşüncelerinin bir özetidir ve herhangi bir resmi görüşü temsil etmez.

Bu makalede yapılan varsayımlar, 100 kişiden fazla teknik ekibi ve günlük trafiği 50 milyonu aşan büyüyen veya olgunlaşmış teknik kuruluşlar için geçerlidir. 100 kişiden az bir ekibe sahip start-up şirketler için iş aramak birinci önceliktir ve organizasyonel yapı optimizasyonu aceleye gelmez, ancak bu makaledeki fikirler yine de referans olarak kullanılabilir.

Büyük haber için geri sayım, 5 gün!

Yedi, ek

1. 2016 DevOps Geliştirme Raporu

2. DevOps'un Temelini Oluşturan Üç İlke

https://itrevolution.com/the-three-ways-principles-underpinning-devops/

3. Netflix'te Mikro Hizmetleri Benimseme: Ekip ve Süreç Tasarımı için Dersler

https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/

4. Yalın Kuruluş: Yüksek performanslı bir kuruluş nasıl ölçeklendirilir ve oluşturulur?

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B01AS1ORWM

5. CapitalOne DevOps Panosu

https://github.com/capitalone/Hygieia

6. Netflix Küresel Bulut Mimarisi

https://www.slideshare.net/adrianco/netflix-global-cloud

7. Kurumsal BT mimarisinin dönüşümü (Alibaba'nın stratejik düşüncesi ve mimari gerçek savaşı)

https://www.amazon.cn/%E4%BC%81%E4%B8%9AIT%E6%9E%B6%E6%9E%84%E8%BD%AC%E5%9E%8B%E4%B9 % 8B% E9% 81% 93-% E9% 92% 9F% E5% 8D% 8E / dp / B0725GPXWQ

8. Conway Yasası

https://en.wikipedia.org/wiki/Conway%27s_law

9. Kötü Bir Sistem Her Zaman İyi Bir İnsanı Yener

https://blog.deming.org/2015/02/a-bad-system-will-beat-a-good-person-every-time/

10. Netflix Açık Kaynak Yazılım Merkezi

https://netflix.github.io/

11. Alibaba Çin-Tayvan stratejisini tamamen başlatıyor

https://www.huxiu.com/article/133482/1.html

12. Bir işletmenin organizasyon yapısı teknik yapıyı nasıl etkiler?

13. Phoenix projesi: efsanevi bir BT operasyonu ve bakımı hikayesi

https://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B016VW1I6U

yazar hakkında

Yang Bo, Papadai Altyapı Çerçevesi Ar-Ge Direktörü. 10 yılı aşkın İnternet dağıtılmış sistem araştırma ve geliştirme ve mimari deneyimiyle şu alanlarda çalıştı: eBay Çin Ar-Ge Merkezi (eBay CDC), kıdemli bir Ar-Ge mühendisi olarak, Yibei açık API platformu Ctrip'in geliştirilmesine bir teknoloji olarak katıldı. Ctrip'in büyük ölçekli SOA sistemi VIPShop'un yapımına liderlik eden Ar-Ge direktörü, konteyner PaaS platformunun araştırma ve mimarisinden sorumlu kıdemli bir bulut platformu mimarı olarak hizmet veriyor.

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın