Platform günlük 700 milyon ziyarete direniyor ve Ar-Ge kalite kontrol süreci tam olarak açıklanıyor
Yazar | Zhou Junpeng
Sorumlu Editör | Wu Xingling
Üretildi | CSDN (ID: CSDNnews)
Ürün kalitesi, kullanıcıları çekmede ve biriktirmede önemli bir faktördür.Sektörde küçük hataların neden olduğu, kullanıcılar veya şirketler için büyük kayıplara neden olabilecek afet sıkıntısı yoktur. İş açısından bakıldığında kalite, ürün itibarının, pazarının ve gelirin arkasındaki artıştır; teknik açıdan yüksek kullanılabilirlik, sistem mimarisini ölçmek için temel göstergelerden biridir. Yüksek kalite gereksinimleri ürün türlerini ayırt etmez, ancak Ar-Ge ekibinin bakış açısından, toB ürünlerinin Ar-Ge ekibinin kalite kontrol bilincini, özellikle platform düzeyinde toB ürünleri güçlendirmesi gerekir.
Tencent Bulut Geliştirme, günde 700 milyondan fazla çağrı alan tek bulut, çok terminalli bir uygulama geliştirme platformudur. Platform düzeyinde bir toB ürünü olarak, bulut geliştirme Ar-Ge ekibi, teslim edilen ürünlerin yüksek oranda erişilebilir olmasını sağlamak için Ar-Ge kalite kontrol yönetiminde nasıl iyi bir iş çıkarır? Bu makale, bulut geliştirme Ar-Ge ekibinin işlevsel bölüm, Ar-Ge özellikleri ve Ar-Ge sürecinin üç boyutundan kalite kontrol yönetimini sizlerle paylaşacak.
Platform düzeyinde toB ürünlerinin kalite krizi ve güven krizi
Platform düzeyinde toB ürünlerinin sağladığı işlevlerin çoğu ince taneli ve bir araya getirilebilir atomik yeteneklerdir.B-tarafı geliştiriciler, C-tarafı uygulamalarının arkasında dolaylı bir destek olan farklı yetenekleri birleştirerek iş mantığını tamamlar.
ToB platformu, C-terminali birinci hat kullanıcıları ile doğrudan temas etmez Bir problem meydana geldikten sonra, C-terminal mantığı ikincil bir iletimden etkilenecektir. Bu nitelik, kalite sorunları olduğunda toB platformu ile toC ürünü arasındaki iki farkı belirler:
-
Büyük etki
-
Geri bildirim zinciri uzunluğu
Büyük etki
Bulut geliştirmeyi örnek olarak ele alırsak, B tarafı geliştiriciler farklı iş modülleri için karşılık gelen bulut işlevlerini yazarlar ve bazı bulut işlevleri de birden fazla iş modülü arasında paylaşılabilir. Bulut işlevinin çalışmasını destekleyen temel sistemde bir sorun olduğunda, etki kapsamı birden çok işlevi kapsayabilir ve ardından iş mantığı katmanına yayılabilir ve öngörülemeyen hasara neden olabilir.
Geri bildirim zinciri uzunluğu
C-son kullanıcılar, uygulamayı kullanırken sorunlarla karşılaştıklarında müşteri hizmetleri, topluluk vb. Aracılığıyla geri bildirimde bulunabilirler.Çoğu Ar-Ge ekibi, sorunları en kısa sürede toplamak ve en kısa sürede çözmek amacıyla Ar-Ge personeli ile doğrudan iletişim için kanallar da sağlar. TOB platformu kullanılarak geliştirilen uygulamalar için, sorunun özü platformun kendisindeyse, B tarafı geliştiricilerin bir araştırma turundan sonra toB platformunun Ar-Ge ekibine daha fazla geri bildirim vermesi gerekir.Geri bildirim zinciri, TOC ürünününkinden çok daha uzundur. Bu, yandan bakıldığında, toB platformunun kalite kontrolünün hassasiyetini ve önemini göstermektedir.
ToB platformunun kalite krizi kolayca bir güven krizine yol açabilir. ToB platformu müşterilere değer sağlamak için bir üretim aracı olarak hizmet eder.Kalite sorunları ortaya çıktığında, müşterilerin ürüne olan güveni düşecek ve ürünün orijinal itibarını ve itibarını geri kazanması son derece zordur. Kalması zaman, veri, pazar ve diğer kombinasyon yumruklarını gerektirir. Gerçekte, "bin millik barajlar karınca yuvalarında çökmüş" olan bazı toB şirketleri var.
Ürün kalitesinin kontrolü sadece teknik bir konu değildir, aynı zamanda yüksek kullanılabilirlikli sistem mimarisinin arkasında süreç ve iş bölümü gibi insan faktörleri de vardır. Ar-Ge süreci sırasında sıkı kalite kontrol yönetimi, ürün kalitesini sağlamak için gerekli bir faktördür. Platform düzeyinde bir toB ürünü olan bulut geliştirme, applet'ler, web ve mobil uygulamalar gibi çok terminalli platformları desteklemektedir.Aşağıda, 60w geliştiricileri destekleyen ve günlük ortalama 700 milyon çağrı hacmine sahip olan bu toB platformunun arkasındaki Ar-Ge süreç yönetimi deneyimini kısaca tanıtacağız.
Ar-Ge süreç yönetimi
Öncelikle bulut geliştirme Ar-Ge ekibinin işlevsel yapısını tanıtın. Aşağıdaki işlevler eksiksiz bir yinelemeli süreçte mevcuttur:
- Proje Yöneticisi PM : Talep duyurularını ve incelemelerini başlatmaktan, yineleme hızını kontrol etmekten ve önceden planlanan süre içinde yinelemenin sorunsuz tamamlanmasını sağlamaktan sorumludur;
- Ürün FO : Yinelemeli bir gereksinimin birden çok alt gereksinimi içermesi olasıdır, her alt gereksinim, belirlenen ürün yöneticisinden sorumludur ve ürün FO ana gereksinimi kontrol eder. FO ürününün bakımı genellikle belirli bir alt gereksinimden sorumlu ürün yöneticisi tarafından yapılır;
- Teknik FO : FO ürününün rolüne benzer şekilde, teknik FO ana gereksinimleri kontrol eder ve her bir alt gereksinim, belirlenen Ar-Ge personelinden sorumludur. Teknik FO'ya ayrıca belirli bir alt gereksinimden sorumlu Ar-Ge personeli tarafından bakılır;
- Ürün Müdürü : Alt gereksinimlerin ürün kontrolünden sorumlu;
- Ar-Ge personeli : Alt gereksinimlerin teknik kontrolünden sorumlu;
- Testçiler : Ar-Ge personelinin işbirliği ile entegrasyon testi, çoklu regresyon ve eksiksiz test senaryo listesinin geliştirilmesi ve gözden geçirilmesinden sorumludur;
- İşletme ve bakım personeli : Ürün ve teknik personel ile olası riskleri değerlendirmek, önceden planlamak ve uygulamaktan sorumludur.
Piramit şeklindeki işlevsel yapı, yinelemeli gereksinimlerin tüm ayrıntılarını kapsayabilir ve FO ve teknik FO ürününün genel planlaması ve programlaması nedeniyle, alt gereksinimlerin önceden tahmin edilemeyen riskleri olduğunda, alt gereksinimleri zaman içinde küresel bir bakış açısıyla koordine edebilirler. Genel programın normal ilerlemesini sağlamak için öncelik ve personel tahsisi.
Ar-Ge spesifikasyonları: "üç izolasyon" kuralına uyun
Genel Ar-Ge spesifikasyonları iki bölüme ayrılmıştır: teknoloji ve süreç yönetimi.
Teknoloji açısından, Ar-Ge ortamının güvenliğini sağlamak için, ilgili personelin "üç izolasyon" kuralına, yani çevresel izolasyon, yetki izolasyonu ve ağ izolasyonu, kesinlikle uyması gerekir.
1. Çevresel izolasyon
Tam yinelemeli döngü, Ar-Ge, ortak hata ayıklama, test etme ve yayınlama süreçlerini gerektirir.Her bağlantı farklı bir ortama karşılık gelir ve her ortam arasındaki veriler paylaşılamaz veya karıştırılamaz.
- Geliştirme ortamı : Ar-Ge personeli için bağımsız çevre alanı;
- Ortak hata ayıklama ortamı Ön uç ve arka uç eklem hata ayıklaması için kullanılan ortam;
- test ortamı : Geliştirme tamamlandıktan sonra entegrasyon test ortamı;
- Deneyim ortamı : Test tamamlandıktan sonra, ürün yöneticisinin tüm süreci deneyimlemesi için ortam;
- Ön sürüm ortamı : Gri tonlamalı sürümden önce, canlı ağı tam olarak simüle eden bir yayın öncesi ortam vardır Bu ortamdaki veriler, yayınlamadan önce son doğrulama ve arabelleğe alma için canlı ağ ile paylaşılır;
- Canlı ağ ortamı : Bu çevrimiçi bir ortamdır ve canlı ağın yayınlanması aşamalı olarak grileştirilmelidir.
İkincisi, izin izolasyonu
Hizmet değişikliklerini içeren gereksinimler için, Ar-Ge personeli değişiklik yapmak için hizmetin bulunduğu sunucuda doğrudan oturum açamaz ve sıçrama tahtası tarafından yetkilendirilmesi gerekir. İzinlerin kesin izolasyonu, sunucunun kararlılığını ve izinlerin merkezi yönetim ve kurtarma işlemlerini korumaktır.
Üç, ağ yalıtımı
Ofis ağları, geliştirme ağları ve genel ağlar arasındaki erişim haklarının ayrılması, BT araştırma ve geliştirme için ortak bir normdur.
Süreç yönetiminde aşağıdaki ilkeleri uygulayın:
-
Gelişmiş planlama: yinelemeli gereksinimlerin olası risklerini önceden tahmin edin ve planlayın;
-
Ar-Ge test programı 1: 1: Tam bir yineleme döngüsü genellikle 4 haftadır ve Ar-Ge ve test programları sırasıyla 2 haftadır.
Ar-Ge süreci: kalite kontrol bilinci tüm süreç boyunca çalışır
Genel süreç içinde, bulut geliştirme diğer birçok Ar-Ge ekibinden çok farklı değildir. Yinelemeli bir süreç sırayla incelenir, geliştirilir, test edilir ve yayınlanır. Kalite kontrol bilinci, detayların kontrolüne yansır.
Talep sunumu
Talep sunumu, yinelemeyi başlattıktan sonraki ilk adımdır. Proje Yöneticisi bir sunum toplantısı başlatır.İhtiyacı olan ürün yöneticileri, toplantıdaki gereksinimlerin arka planını, önceliğini, önemini, maliyetini ve beklentilerini açıklar ve tüm katılımcıların ortak bir görüşü vardır Vaaz edilen ihtiyaçlar, bu yinelemeye dahil edilip edilmeyeceklerini belirlemek için değerlendirilir. Son sunumun ardından, bu yineleme için gereksinimlerin listesi belirlenir ve teknik inceleme sürecine girilir.
Teknik inceleme
Teknik inceleme proje yöneticisi tarafından başlatılır ve tüm fonksiyonel personel mevcut olmalıdır. Ürün yöneticisi, talep listesini önceden oluşturur ve incelemeyi başlatırken satır satır açıklar ve ardından Ar-Ge personeli ve test uzmanları teknik fizibilite değerlendirmesini yapar, talep açıklamasındaki belirsiz alanları tartışır ve düzeltir ve olası varlığı tahmin eder. Riskler ve ilgili planlar. Gereksinimler netleştirildikten sonra, Ar-Ge ve test programları ve ilgili programları verilir. Ar-Ge ve test için zamanlama oranı 1: 1'dir.
Ar-Ge
Ar-Ge aşamasına girmeden önce, test uzmanlarının bu talebe dayalı bir test senaryosu listesi hazırlamaları ve Ar-Ge personeli ile ürün yöneticisinin birlikte gözden geçirmesi, tamamlaması ve düzeltmesi gerekir.
Ön uç ve arka uç Ar-Ge personeli, ilgili geliştirme ortamlarında kod yazar.Servis değişiklikleri söz konusuysa, çevresel yalıtım özelliklerine kesinlikle uymalı ve bir sıçrama tahtası yardımıyla sunucuda oturum açmalıdır.
Ölçek
Test için gereklilikleri sunmadan önce, biri vazgeçilmez olan iki hazırlık görevi vardır:
-
Ar-Ge personelinin, test senaryosu listesinin çıktısına göre kendi kendini test etmesi ve bir kendi kendine test raporu hazırlaması gerekir;
-
Ürün yöneticisinin, ortak hata ayıklama ortamında tüm işlevi ve işlem sürecini deneyimlemesi gerekir.
Test uzmanları ilk olarak, Ar-Ge personeli ve ürün yöneticilerinin birlikte yardım ettiği bir test ortamında işlevsel doğrulamayı gerçekleştirir. Test tamamlandıktan sonra, geliştirici kodu deneyim ortamına dağıtır ve ardından test uzmanı tam bir durum regresyonu gerçekleştirir ve ardından bunu geçtikten sonra yayın öncesi ortama dağıtır. Yayın standardına ancak tam bir gerilemeden sonra ulaşılabilir. Yani, test ortamında bir tam test ve iki regresyon gereklidir.
serbest bırakmak
Hizmet sürümü, kademeli gri ölçek stratejisini kesinlikle takip etmelidir ve SDK sürümü "alfa- > beta- > Ek olarak, işlevlerin değişimi sadece kodun kendisi değildir Farklı ürün türleri genellikle dokümantasyonu ve çok kanallı çevresel çalışmaları içerir.Örneğin, hizmetlerin serbest bırakılması çok uçlu SDK'yı etkileyecektir. API ve ona karşılık gelen belgelerin eşzamanlı olarak güncellenmesi gerekir.Bu nedenle, hizmet modülüne veya SDK kanalına göre özel bölümleme yapılması gerekir.Sürüm dışa aktarımının benzersizliğini sağlamak ve sürümden önce sıkı bir çalışma listesi geçişi gerçekleştirmek gerekir.
dönüş
Gri sürüm işlemi sırasında ve tam sürümden sonra, test uzmanlarının aynı anda izlemesi ve serbest bırakılan işlevler üzerinde regresyon testleri gerçekleştirmesi gerekir ve bu yineleme, tamamen geçildiğinde sona erecektir.
Genel süreç çoğu teknik Ar-Ge ekibiyle aynı olsa da, bulut geliştirme ekibinin kalite kontrol yönetimi konusundaki farkındalığı şu şekilde yansıtılır: Eksiksiz ve katı bir standart sistem yardımıyla, her bağlantıda yanlış gidebilecek ayrıntılar teknoloji ve personelden geçirilir. Çift kapsama açısı, kalite sorunlarını büyük ölçüde azaltabilir.
sonuç olarak
On yıllarca bilgisayar teknolojisinin bugüne kadar geliştirilmesinden sonra, makinelerin yardımıyla birçok insan işi tamamlanabilir veya hatta tamamen değiştirilebilir. Teknolojinin büyüklüğü şüphe götürmez ama insan faktörü de vazgeçilmezdir. İster teknoloji eksikliği, ister insan hatası olsun, ürünün kalitesi dikkatsizlikle kontrol edilemez.
Platform düzeyinde bir toB ürünü olarak bulut geliştirme, teknolojinin ve yüksek kullanılabilirliğin arkasındaki insanların ikili nimetleridir. Bulut geliştirme ve Ar-Ge ekibinin teknik yeteneklerini geliştirirken, içindeki insanların büyüklüğünü de göz ardı etmediler.Gelecekte de bu prensibi benimsemeye ve Ar-Ge kalite kontrol yönetiminin her ayrıntısına teknolojinin ve insanın ikili faktörüne nüfuz etmeye devam edeceğiz. .
Yazar tanıtımı: Tencent kıdemli ön uç mühendisi Zhou Junpeng, Cloudbase ile ilgili teknoloji araştırma ve geliştirme bulut geliştirmeden sorumlu Tencent Cloud Cloud Development CloudBase ekibinde çalışıyor. Qcon2017 öğretim görevlisi, GMTC 2018/2019 yapımcısı, ana araştırma yönü, ön uç grafik programlama, mühendislik ve web uygulama katmanı mimarisidir. "Front-end Engineering: System Design and Practice" ve "Front-end Technical Architecture and Engineering" kitaplarının yazarı.
Yapay zeka çağında, programcılar neden pahalı?
Baidu'nun eski baş mimarı işine başladı ve iki yılda on milyonlarca dolar topladı. Yeni yapay zeka ilaçlarının geliştirilmesinin altın on yılı başlatacağını söyledi.
Tanrım, hala dene-yakala-nihayet kullanıyorsun
Pekin'deki Dördüncü Çevre Yolu'ndaki trafik sıkışıklığının tetiklediği büyük akıllı ulaşım fikri
Ngin'den Pandownload'e, programcılar hapishane programlamasından nasıl kaçınabilir?
Web1.0'dan Web3.0'a: İnternetin son yıllarda gelişimi ve gelecekteki yönünün ayrıntılı analizi
