Bir vaqtda bir nechta IT-pudratchi: multivendor model

Qisqacha: bu qachon ishlaydi

Bir vaqtda bir nechta pudratchi — odatiy amaliyot: biri mobil ilovani, boshqasi veb-kabinetni, uchinchisi buxgalteriya tizimi bilan integratsiyani qiladi. Bu tor ekspertizaga kirish imkonini beradi, bitta kompaniyaga qaramlikni kamaytiradi va ishlarni parallel olib borishga imkon yaratadi.

Lekin modelning o‘z narxi bor: jamoalar orasidagi bog‘lanish joylari. Multivendor loyihalardagi deyarli barcha muammolar komponentlar ichida emas, ularning chegaralarida paydo bo‘ladi. Shuning uchun buyurtmachining asosiy ishi — har bir pudratchini nazorat qilish emas, balki shu chegaralarni loyihalash va qo‘riqlash.

Ishni pudratchilar o‘rtasida qanday bo‘lish kerak

Yaxshi chegara — jamoalar u orqali kam va rasmiy muloqot qiladigan chegara.

• Tizim komponentlari bo‘yicha: mobil ilova, backend, admin panel, integratsiyalar. Eng tushunarli variant.
• Biznes-domenlar bo‘yicha: katalog, buyurtmalar, to‘lovlar. Mustaqil servislarga ega yirik tizimlar uchun mos.
• Ish turi bo‘yicha: ishlab chiqish birlarida, testlash yoki infratuzilma boshqalarida. Ayniqsa aniq topshirish jarayonini talab qiladi.

Nimadan qochish kerak: umumiy texnik rahbarsiz bitta kod bazasida ikki pudratchi. Bu uslub, arxitektura qarorlari va mas’uliyat bo‘yicha nizoni deyarli kafolatlaydi.

Interfeyslar va egalik

Pudratchilar orasidagi har bir chegara og‘zaki kelishuv bilan emas, hujjat bilan tasvirlanishi kerak.

1. API kontrakti. Endpointlar, formatlar, xatolar va versiyalar tavsifi — masalan, OpenAPI spetsifikatsiyasida. O‘zgarishlar faqat kelishuv orqali.
2. Ma’lumotlar kontrakti. Qaysi obyektlarni kim yaratadi va har bir maydon uchun haqiqat manbai kim.
3. Test stendlari va moklar. Jamoa qo‘shnisining tayyor bo‘lishini kutmasdan ishlay olishi uchun.
4. Mas’uliyat matritsasi. Har bir komponent uchun — bitta ega.

Infratuzilma, repozitoriylar, domenlar va servis akkauntlari buyurtmachiga tegishli bo‘lishi kerak. Pudratchilar kirish huquqini oladi, lekin egalik qilmaydi.

Relizlarni qanday kelishish kerak

• Umumiy reliz kalendarini yuriting va boshqalarga ta’sir qiladigan o‘zgarishlarni oldindan belgilang.
• API versiyalash va orqaga moslikdan foydalaning: eski klientlar yangilari yangilanguncha ishlashda davom etadi.
• Bog‘lanish joyiga tegadigan har bir relizdan oldin umumiy stendda integratsion testlash o‘tkazing.
• Vazifa va insidentlar uchun yagona format kelishib oling: umumiy tizim yoki hech bo‘lmaganda jamoalararo savollar uchun umumiy kanal.
• Barcha jamoa vakillari bilan muntazam sinxronizatsiya o‘tkazing — qisqa va aniq.

Aybni bir-biriga ag‘darishdan qanday qochish kerak

«Bu bizda emas, ularda» holati — chegaralar xiralashganining eng keng tarqalgan belgisi.

• Bog‘lanish joylarida loglar va monitoring: ular kim nima yuborganini va nima qabul qilinganini ko‘rsatadi.
• Insidentlarga javob berishning aniq muddatlari bilan har bir pudratchi uchun SLA.
• Birinchi javob beruvchi qoidasi: insidentni olgan tomon uni tahlil qiladi va kerak bo‘lsa, shunchaki yo‘naltirmasdan, dalillar bilan keyingisiga topshiradi.
• Aybdor qidirmasdan insident tahlili: maqsad — aybdorni topish emas, jarayon yoki kontraktni tuzatish.

Yetakchi integrator qachon kerak

Yetakchi integrator — butun tizim uchun javob beradigan kompaniya yoki odam: arxitektura, bog‘lanish joylari, umumiy reliz va integratsiya sifati.

U kerak, agar:

• pudratchilar ikki-uchtadan ko‘p va komponentlar bir-biriga kuchli bog‘langan bo‘lsa;
• sizda o‘z texnik rahbaringiz yoki arxitektoringiz bo‘lmasa;
• insidentlar muntazam ravishda jamoalar orasida qotib qolsa;
• tizim biznes uchun muhim va to‘xtab qolish qimmatga tushsa.

Integrator o‘zingizning CTO yoki arxitektoringiz, kengaytirilgan rolga ega pudratchilardan biri yoki alohida kompaniya bo‘lishi mumkin. Muhimi, uning vakolatlari yozib qo‘yilgan bo‘lsin: u kontrakt o‘zgarishlarini tasdiqlaydi va bog‘lanish joylarida ishni qabul qiladi.