Hər şeyə təsir edən bir təqdimat hekayəsi

Reallığın Düşmənləri 12f-2 ilə

Aprelin sonunda, White Walkers Winterfell-i mühasirəyə alarkən, bizimlə daha maraqlı bir şey oldu; biz qeyri-adi bir çıxış etdik. Prinsipcə, biz daim istehsala yeni funksiyalar təqdim edirik (hamı kimi). Amma bu fərqli idi. Bunun miqyası elə idi ki, edə biləcəyimiz potensial səhvlər bütün xidmətlərimizə və istifadəçilərimizə təsir göstərəcək. Nəticədə, biz plana uyğun olaraq, planlaşdırılmış və elan edilmiş fasilələr müddətində satış üçün heç bir nəticə vermədik. Məqalədə buna necə nail olduğumuz və hər kəsin evdə necə təkrarlaya biləcəyi haqqındadır.

İndi qəbul etdiyimiz memarlıq və texniki qərarları təsvir etməyəcəyəm və ya hamısının necə işlədiyini söyləməyəcəyəm. Bunlar daha çox müşahidə etdiyim və birbaşa iştirak etdiyim ən çətin buraxılışlardan birinin necə baş verdiyi barədə kənarlarda qeydlərdir. Tamlıq və ya texniki təfərrüatlar iddia etmirəm, bəlkə də başqa məqalədə görünəcəklər.

Fon + bu hansı funksionallıqdır?

Biz bulud platforması qururuq Mail.ru Bulud Həlləri (MCS), mən texniki direktor kimi işləyirəm. İndi isə platformamıza bütün istifadəçi hesablarının, istifadəçilərinin, parollarının, rollarının, xidmətlərinin və s. vahid idarə edilməsini təmin edən IAM (Identity and Access Management) əlavə etməyin vaxtıdır. Buludda nə üçün lazım olduğu açıq bir sualdır: bütün istifadəçi məlumatları orada saxlanılır.

Adətən belə şeylər hər hansı bir layihənin başlanğıcında tikilməyə başlayır. Ancaq tarixən MCS-də işlər bir az fərqli olub. MCS iki hissədən ibarətdir:

• Öz Keystone avtorizasiya modulu ilə Openstack,
• Mail.ru Bulud layihəsi əsasında Hotbox (S3 yaddaşı),

ətrafında yeni xidmətlər meydana çıxdı.

Əslində bunlar iki fərqli icazə növü idi. Üstəlik, biz bəzi ayrı Mail.ru inkişaflarından istifadə etdik, məsələn, ümumi Mail.ru parol anbarı, həmçinin öz-özünə yazılmış openid konnektoru, bunun sayəsində Horizon panelində SSO (sondan sona avtorizasiya) təmin edildi. virtual maşınların (doğma OpenStack UI).

Bizim üçün IAM yaratmaq, hamısını vahid sistemə, tamamilə özümüzə aid etmək demək idi. Eyni zamanda, biz bu yolda heç bir funksionallığı itirməyəcəyik, əksinə, onu refaktorlaşdırmadan şəffaf şəkildə dəqiqləşdirməyə və funksionallıq baxımından miqyasına salmağa imkan verəcək gələcək üçün təməl yaradacağıq. Həmçinin başlanğıcda istifadəçilərin xidmətlərə çıxış (mərkəzi RBAC, rola əsaslanan giriş nəzarəti) və bəzi digər xırda şeylər üçün rol modeli var idi.

Tapşırığın mənasız olduğu ortaya çıxdı: python və perl, bir neçə arxa plan, müstəqil yazılmış xidmətlər, bir neçə inkişaf qrupu və adminlər. Ən əsası isə döyüş istehsalı sistemində minlərlə canlı istifadəçi var. Bütün bunlar yazılmalı və ən əsası itkisiz yayılmalı idi.

Nə yayacağıq?

Çox kobud desək, təxminən 4 ay ərzində aşağıdakıları hazırladıq:

• Biz əvvəllər infrastrukturun müxtəlif hissələrində işləyən funksiyaları birləşdirən bir neçə yeni demon yaratdıq. Qalan xidmətlərə bu iblislər şəklində yeni bir arxa plan təyin edildi.
• Biz bütün xidmətlərimiz üçün əlçatan olan, ehtiyacımız olduqda sərbəst şəkildə dəyişdirilə bilən öz mərkəzi parol və açar anbarımızı yazdıq.
• Keystone üçün sıfırdan 4 yeni backend yazdıq (istifadəçilər, layihələr, rollar, rol təyinatları), bu, əslində öz verilənlər bazasını əvəz etdi və indi istifadəçi parollarımız üçün vahid depo rolunu oynayır.
• Biz bütün Openstack xidmətlərimizə bu siyasətləri hər bir serverdən yerli olaraq oxumaq əvəzinə öz siyasətləri üçün üçüncü tərəf siyasət xidmətinə keçməyi öyrətdik (bəli, Openstack standart olaraq belə işləyir!)

Belə əsaslı yenidən iş müxtəlif inkişaf qrupları tərəfindən yazılmış bir neçə sistemdə böyük, mürəkkəb və ən əsası sinxron dəyişikliklər tələb edir. Quraşdırıldıqdan sonra bütün sistem işləməlidir.

Bu cür dəyişiklikləri necə yaymaq və onu pozmamaq olar? Əvvəlcə gələcəyə bir az baxmaq qərarına gəldik.

Yayılma strategiyası

• Məhsulu bir neçə mərhələdə yaymaq mümkün olardı, lakin bu, inkişaf müddətini üç dəfə artıracaq. Bundan əlavə, bir müddət verilənlər bazalarında məlumatların tam desinxronizasiyasına malik olardıq. Öz sinxronizasiya alətlərinizi yazmalı və uzun müddət birdən çox məlumat mağazası ilə yaşamalı olacaqsınız. Və bu, müxtəlif risklər yaradır.
• İstifadəçi üçün şəffaf şəkildə hazırlana biləcək hər şey əvvəlcədən həyata keçirilib. 2 ay çəkdi.
• Biz özümüzə bir neçə saat dayanmağa icazə verdik - yalnız istifadəçi əməliyyatları üçün resursların yaradılması və dəyişdirilməsi üçün.
• Artıq yaradılmış bütün resursların işləməsi üçün fasilələr qəbuledilməz idi. Planlaşdırmışdıq ki, təqdimat zamanı resurslar fasiləsiz işləməli və müştərilərə təsir göstərməlidir.
• Bir şey səhv olarsa, müştərilərimizə təsirini azaltmaq üçün bazar günü axşamdan istifadəyə vermək qərarına gəldik. Gecələr virtual maşınları daha az müştəri idarə edir.
• Biz bütün müştərilərimizə xəbərdarlıq etmişik ki, istifadəyə verilməsi üçün seçilmiş müddət ərzində xidmət idarəçiliyi əlçatan olmayacaq.

Digression: rollout nədir?

<ehtiyat, fəlsəfə>

Hər bir İT mütəxəssisi asanlıqla təqdimatın nə olduğuna cavab verə bilər. Siz CI/CD quraşdırırsınız və hər şey avtomatik olaraq mağazaya çatdırılır. 🙂

Təbii ki, bu doğrudur. Lakin çətinlik ondadır ki, müasir kodun çatdırılmasının avtomatlaşdırılması vasitələri ilə buraxılışın özü haqqında anlayış itir. Müasir nəqliyyata baxanda təkərin ixtirasının epikliyini necə unudursunuz. Hər şey o qədər avtomatlaşdırılmışdır ki, təqdimat çox vaxt bütün mənzərəni başa düşmədən həyata keçirilir.

Və bütün şəkil belədir. Yayım dörd əsas aspektdən ibarətdir:

1. Məlumatların dəyişdirilməsi daxil olmaqla kodun çatdırılması. Məsələn, onların köçləri.
2. Kodun geri qaytarılması bir şey səhv olarsa geri qayıtmaq qabiliyyətidir. Məsələn, ehtiyat nüsxələri yaratmaqla.
3. Hər buraxılış/geri qaytarma əməliyyatının vaxtı. İlk iki nöqtənin hər hansı bir əməliyyatının vaxtını başa düşməlisiniz.
4. Təsirə məruz qalan funksionallıq. Həm gözlənilən müsbət, həm də mümkün mənfi təsirləri qiymətləndirmək lazımdır.

Uğurlu yayım üçün bütün bu aspektlər nəzərə alınmalıdır. Adətən yalnız birinci və ya ən yaxşı halda ikinci nöqtə qiymətləndirilir və sonra buraxılış uğurlu sayılır. Ancaq üçüncü və dördüncü daha vacibdir. Təqdimat bir dəqiqə əvəzinə 3 saat çəksə, hansı istifadəçi bunu istərdi? Yaxud təqdimat zamanı lazımsız bir şey təsirlənərsə? Yoxsa bir xidmətin dayanması gözlənilməz nəticələrə gətirib çıxaracaq?

Akt 1..n, buraxılışa hazırlıq

Əvvəlcə görüşlərimizi qısaca təsvir etməyi düşündüm: bütün komanda, onun hissələri, qəhvə nöqtələrində çoxlu müzakirələr, mübahisələr, testlər, beyin fırtınaları. Sonra bunun lazımsız olacağını düşündüm. Dörd aylıq inkişaf həmişə bundan ibarətdir, xüsusən də siz davamlı olaraq çatdırıla bilən bir şey yazdığınız zaman deyil, canlı sistem üçün böyük bir xüsusiyyətdir. Bu, bütün xidmətlərə təsir edir, lakin istifadəçilər üçün “veb interfeysindəki bir düymə”dən başqa heç nə dəyişməməlidir.

Hər yeni görüşdən necə istifadə edəcəyimizə dair anlayışımız dəyişdi və olduqca əhəmiyyətli. Məsələn, biz bütün faktura məlumat bazamızı yeniləyəcəkdik. Lakin biz vaxtı hesabladıq və başa düşdük ki, bunu ağlabatan müddət ərzində etmək mümkün deyil. Faktura məlumat bazasını parçalamaq və arxivləşdirmək bizə demək olar ki, əlavə bir həftə çəkdi. Və gözlənilən yayılma sürəti hələ də qənaətbəxş olmadıqda, bütün bazanın sürükləndiyi əlavə, daha güclü avadanlıq sifariş etdik. Bu, biz bunu daha tez etmək istəmədiyimizdən deyil, amma indiki ehtiyac bizi heç bir seçim buraxmadı.

Bizlərdən birinin təqdimatın virtual maşınlarımızın mövcudluğuna təsir göstərə biləcəyinə şübhə etdikdə, biz bir həftə sınaqlar, təcrübələr, kod təhlili apardıq və bunun bizim istehsalımızda baş verməyəcəyini aydın şəkildə başa düşdük və hətta ən şübhəli insanlar belə razılaşdı. bununla.

Bu vaxt, texniki dəstəkdən olan uşaqlar müştərilərə qoşulma üsulları ilə bağlı təlimatlar yazmaq üçün öz müstəqil təcrübələrini həyata keçirdilər. İstifadəçi UX üzərində işlədilər, təlimatlar hazırladılar və şəxsi məsləhətlər verdilər.

Mümkün olan bütün satış əməliyyatlarını avtomatlaşdırdıq. Hər bir əməliyyat, hətta ən sadələri belə, skript edildi və daim sınaqlar keçirildi. Onlar xidməti söndürməyin ən yaxşı yolu haqqında mübahisə etdilər - demonu buraxın və ya firewall ilə xidmətə girişi bloklayın. Biz təqdimatın hər bir mərhələsi üçün komandaların siyahısı yaratdıq və onu daim yeniləyirik. Biz bütün təqdimat işləri üçün vaxtları olan Gantt diaqramını çəkdik və daim yenilədik.

Və sairə…

Çıxışdan əvvəl son hərəkət

...çıxarmaq vaxtıdır.

Necə deyərlər, sənət əsərini tamamlamaq olmaz, onun üzərində işləmək kifayətdir. Hər şeyi tapa bilməyəcəyinizi başa düşərək, bütün mümkün fərziyyələri etdiyinizə, bütün kritik səhvləri bağladığınıza və bütün iştirakçılar əllərindən gələni etdiyinə inanaraq, səy göstərməlisiniz. Nə qədər çox kod yaysanız, özünüzü buna inandırmaq bir o qədər çətindir (bundan başqa hamı başa düşür ki, hər şeyi qabaqcadan görmək mümkün deyil).

İstifadəçilərimiz üçün gözlənilməz təsirlər və dayanma müddətləri ilə bağlı bütün riskləri ödəmək üçün mümkün olan hər şeyi etdiyimizə əmin olduqdan sonra işə başlamağa hazır olduğumuza qərar verdik. Yəni, hər şey səhv ola bilər:

1. (Bizim üçün müqəddəs, ən qiymətli) istifadəçi infrastrukturuna təsir etmək,
2. Funksionallıq: istifadəyə verildikdən sonra xidmətimizdən istifadə ondan əvvəlki kimi olmalıdır.

Yayılır

İki rulon, 8 mane olmur

Biz istifadəçilərdən gələn bütün sorğular üçün 7 saat fasilə veririk. Hal-hazırda bizim həm yayım planımız, həm də geri qaytarma planımız var.

• Yayımlamanın özü təxminən 3 saat çəkir.
• Test üçün 2 saat.
• 2 saat - dəyişikliklərin mümkün geri qaytarılması üçün ehtiyat.

Hər bir hərəkət üçün Gantt qrafiki tərtib edilib, nə qədər vaxt lazımdır, ardıcıl olaraq nə baş verir, paralel olaraq nə edilir.

İlkin versiyalardan biri (paralel icra olmadan) yayılmış Gantt diaqramının bir parçası. Ən Dəyərli Sinxronizasiya Aləti

Bütün iştirakçıların təqdimatda öz rolu, hansı tapşırıqları yerinə yetirdikləri və nəyə görə cavabdeh olduqları müəyyən edilir. Biz hər mərhələni avtomatlaşdırmağa, yaymağa, geri çevirməyə, rəy toplamağa və yenidən yaymağa çalışırıq.

Hadisələrin salnaməsi

Belə ki, aprelin 15-u, bazar günü axşam saat 29-də 10 nəfər işə gəlib. Əsas iştirakçılardan əlavə, bəziləri sadəcə komandanı dəstəkləmək üçün gəldilər, buna görə onlara xüsusi təşəkkürlər.

Əsas testçimizin tətildə olduğunu da qeyd etmək lazımdır. Test etmədən yaymaq mümkün deyil, biz variantları araşdırırıq. Bir həmkarımız bizi tətildən sınamağa razılaşır, buna görə bütün komandadan böyük minnətdarlıq alır.

00:00. Dayan
İstifadəçi müraciətlərini dayandırırıq, texniki iş yazılan lövhəni asırıq. Monitorinq qışqırır, amma hər şey normaldır. Düşməli olandan başqa heç bir şeyin düşmədiyini yoxlayırıq. Və biz miqrasiya ilə bağlı işə başlayırıq.

Hər kəsin nöqtə-nöqteyi-nəzərində çap olunmuş təqdimat planı var, hamı kimin nə etdiyini və hansı anda etdiyini bilir. Hər bir hərəkətdən sonra, biz onları aşmamaq üçün vaxtları yoxlayırıq və hər şey plana uyğun gedir. Hazırkı mərhələdə birbaşa təqdimatda iştirak etməyənlər həmkarlarını narahat etməmək üçün onlayn oyuncaq (Xonotic, type 3 quacks) buraxaraq hazırlaşırlar. 🙂

02:00. Yuvarlandı
Xoş sürpriz - verilənlər bazalarımızın və miqrasiya skriptlərimizin optimallaşdırılması sayəsində təqdimatı bir saat əvvəl bitiririk. Ümumi fəryad: "Yuvarlandı!" Bütün yeni funksiyalar istehsaldadır, lakin hələlik yalnız biz onları interfeysdə görə bilirik. Hər kəs test rejiminə keçir, onları qruplara ayırır və sonunda nə baş verdiyini görməyə başlayır.

Çox yaxşı alınmadı, biz bunu 10 dəqiqədən sonra, heç bir şey bağlı olmadıqda və ya komanda üzvlərinin layihələrində işlədikdə başa düşürük. Sürətli sinxronizasiya, problemlərimizi səsləndiririk, prioritetləri təyin edirik, komandalara bölünür və sazlamaya başlayırıq.

02:30. Dörd gözə qarşı iki böyük problem
Biz iki böyük problem tapırıq. Biz başa düşdük ki, müştərilər bəzi əlaqəli xidmətləri görməyəcək və tərəfdaş hesablarla bağlı problemlər yaranacaq. Hər ikisi bəzi kənar hallar üçün qeyri-kamil miqrasiya skriptləri ilə bağlıdır. Biz bunu indi düzəltmək lazımdır.

Bunu qeyd edən sorğuları ən azı 4 gözlə yazırıq. Biz onların işlədiyinə və heç nəyi pozmadığına əmin olmaq üçün onları istehsaldan əvvəl sınaqdan keçiririk. Daha da yuvarlana bilərsiniz. Eyni zamanda, biz müntəzəm inteqrasiya testimizi həyata keçiririk ki, bu da daha bir neçə məsələni ortaya qoyur. Onların hamısı kiçikdir, lakin onların da təmirə ehtiyacı var.

03:00. -2 problem +2 problem
Əvvəlki iki böyük problem aradan qaldırıldı, demək olar ki, bütün kiçik problemlər də. Düzəlişlərlə məşğul olmayanların hamısı öz hesablarında aktiv şəkildə işləyir və tapdıqlarını bildirirlər. Biz prioritetləşdiririk, komandalar arasında bölüşdürürük və kritik olmayan əşyaları səhərə buraxırıq.

Yenidən testlər keçiririk, onlar iki yeni böyük problem aşkar edirlər. Bütün xidmət siyasətləri düzgün gəlmir, ona görə də bəzi istifadəçi sorğuları avtorizasiyadan keçmir. Üstəlik tərəfdaş hesabları ilə bağlı yeni problem. Baxmağa tələsək.

03:20. Fövqəladə sinxronizasiya
Bir yeni məsələ düzəldildi. İkincisi, biz fövqəladə sinxronizasiya təşkil edirik. Nə baş verdiyini başa düşürük: əvvəlki bir problemi həll etdi, amma başqasını yaratdı. Bunu necə düzgün və nəticəsiz edəcəyimizi anlamaq üçün fasilə veririk.

03:30. Altı göz
Biz bazanın son vəziyyətinin necə olacağını başa düşürük ki, hər şey bütün tərəfdaşlar üçün yaxşı olsun. Biz 6 gözlə sorğu yazırıq, onu istehsaldan əvvəl yayırıq, sınaqdan keçiririk, istehsal üçün yayırıq.

04:00. Hər şey işləyir
Bütün testlər keçdi, heç bir kritik problem görünmür. Zaman-zaman komandada nə isə kiminsə xeyrinə olmur, dərhal reaksiya veririk. Çox vaxt həyəcan siqnalı yanlışdır. Ancaq bəzən bir şey gəlmir və ya ayrı bir səhifə işləmir. Otururuq, düzəldirik, düzəldirik, düzəldirik. Ayrı bir komanda son böyük funksiyanı işə salır - faktura.

04:30. Geri dönüş nöqtəsi
Geri dönmə nöqtəsi yaxınlaşır, yəni geriyə yuvarlanmağa başlasaq, bizə verilən dayanma vaxtı qarşılamayacağımız zamandır. Hər şeyi bilən və qeyd edən, lakin müştərilərdən pul silməkdən inadla imtina edən hesablaşma ilə bağlı problemlər var. Fərdi səhifələrdə, hərəkətlərdə və statuslarda bir neçə səhv var. Əsas funksionallıq işləyir, bütün testlər uğurla keçir. Yayımlamanın baş tutduğuna qərar verdik, geri çəkilməyəcəyik.

06:00. UI-də hər kəs üçün açıqdır
Səhvlər düzəldildi. İstifadəçiləri cəlb etməyən bəziləri sonraya buraxılır. İnterfeysi hər kəsə açırıq. Biz faktura üzərində işləməyə davam edirik, istifadəçi rəyini və monitorinq nəticələrini gözləyirik.

07:00. API yüklənməsi ilə bağlı problemlər
Aydın olur ki, API-mizdəki yükü bir az səhv planlaşdırdıq və problemi müəyyən edə bilməyən bu yükü sınaqdan keçirdik. Nəticədə, sorğuların ≈5%-i uğursuz olur. Gəlin səfərbər olaq və səbəb axtaraq.

Hesablama inadkardır və işləmək də istəmir. Dəyişiklikləri sakit şəkildə həyata keçirmək üçün onu gec vaxta qədər təxirə salmaq qərarına gəldik. Yəni bütün resurslar orada toplanır, lakin müştərilərdən silinmələr keçmir. Əlbəttə ki, bu problemdir, lakin ümumi təqdimatla müqayisədə bu, əhəmiyyətsiz görünür.

08:00. API düzəldin
Yük üçün bir düzəliş hazırladıq, uğursuzluqlar aradan qalxdı. Evə getməyə başlayırıq.

10:00. Hamısı
Hər şey düzəldilmişdir. Monitorinqdə sakitdir və müştərilərin yerində komanda tədricən yuxuya gedir. Hesablama qalır, sabah bərpa edəcəyik.

Sonra gün ərzində bəzi müştərilərimiz üçün qeydləri, bildirişləri, qayıdış kodlarını və fərdiləşdirmələri düzəldən təqdimatlar oldu.

Beləliklə, təqdimat uğurlu oldu! Bu, əlbəttə ki, daha yaxşı ola bilərdi, amma mükəmməlliyə nail olmaq üçün bizə nəyin çatmadığı barədə nəticə çıxardıq.

Ümumi

Təqdimat üçün 2 aylıq aktiv hazırlıq zamanı bir neçə saatdan bir neçə günə qədər davam edən 43 tapşırıq yerinə yetirildi.

Yayım zamanı:

• yeni və dəyişdirilmiş cinlər - 5 monolit əvəz edən 2 ədəd;
• verilənlər bazası daxilində dəyişikliklər - istifadəçi məlumatları olan bütün 6 verilənlər bazamız təsirləndi, üç köhnə verilənlər bazasından bir yenisinə yükləmələr edildi;
• tamamilə yenidən dizayn edilmiş ön hissə;
• endirilmiş kodun miqdarı - 33 min sətir yeni kod, ≈ testlərdə 3 min sətir kod, ≈ 5 min sətir miqrasiya kodu;
• bütün məlumatlar tamdır, heç bir müştərinin virtual maşını zədələnməmişdir. 🙂

Yaxşı yayım üçün yaxşı təcrübələr

Bu çətin vəziyyətdə bizə yol göstərdilər. Lakin, ümumiyyətlə, hər hansı bir yayım zamanı onlara riayət etmək faydalıdır. Lakin təqdimat nə qədər mürəkkəb olsa, onların oynadığı rol bir o qədər böyükdür.

1. Etməli olduğunuz ilk şey, yayımın istifadəçilərə necə təsir edə biləcəyini və ya təsir edəcəyini anlamaqdır. Boş vaxtlar olacaqmı? Əgər belədirsə, dayanma müddəti nədir? Bu istifadəçilərə necə təsir edəcək? Mümkün olan ən yaxşı və ən pis ssenarilər hansılardır? Və riskləri əhatə edin.
2. Hər şeyi planlaşdırın. Hər mərhələdə siz təqdimatın bütün aspektlərini başa düşməlisiniz:
   • kodun çatdırılması;
   • kodun geri qaytarılması;
   • hər əməliyyatın vaxtı;
   • təsirlənmiş funksionallıq.
3. Təqdimatın bütün mərhələləri, eləcə də onların hər birindəki risklər aydınlaşana qədər ssenarilər üzərində oynayın. Əgər hər hansı bir şübhəniz varsa, fasilə verib şübhəli mərhələni ayrıca araşdıra bilərsiniz.
4. Hər bir mərhələ istifadəçilərimizə kömək edərsə, təkmilləşdirilə bilər və təkmilləşdirilməlidir. Məsələn, dayanma müddətini azaldacaq və ya bəzi riskləri aradan qaldıracaq.
5. Geri qaytarma testi kodun çatdırılması testindən daha vacibdir. Geriyə qayıtma nəticəsində sistemin orijinal vəziyyətinə qayıdacağını yoxlamaq və bunu testlərlə təsdiqləmək lazımdır.
6. Avtomatlaşdırıla bilən hər şey avtomatlaşdırılmalıdır. Avtomatlaşdırıla bilməyən hər şey əvvəlcədən fırıldaqçı vərəqdə yazılmalıdır.
7. Uğur meyarını qeyd edin. Hansı funksionallıq mövcud olmalıdır və nə vaxt? Bu baş vermirsə, geri qaytarma planını işə salın.
8. Və ən əsası - insanlar. Hər kəs nə etdiyini, niyə və nəyin yayılması prosesindəki hərəkətlərindən asılı olduğunu bilməlidir.

Və bir cümlə ilə, yaxşı planlaşdırma və işlənmə ilə siz istədiyiniz hər şeyi satış üçün heç bir nəticə vermədən həyata keçirə bilərsiniz. Hətta istehsalda bütün xidmətlərinizə təsir edəcək bir şey.

Mənbə: www.habr.com