Quality attribute-lər hər şeyi müəyyən edir

Functional requirement-lər sistemin nə etdiyini deyir. Quality attribute-lər isə bunu nə qədər yaxşı etdiyini, hansı şəraitdə etdiyini və bu şərait pozulanda nə baş verdiyini deyir. Eyni feature-lərə malik iki sistem architecture baxımından kökündən fərqli ola bilər, çünki fərqli keyfiyyətləri prioritetləşdirirlər.

Bu fəsildə geniş yayılmış attribute-lər adlandırılır, onları konkretləşdirməyin yolu göstərilir və niyə mütləq sıralanmalı olduqları izah edilir.

Adi şübhəlilər

Attribute	Cavab verdiyi sual
Performance	Tək bir request nə qədər tez tamamlanır və saniyədə nə qədər iş görə bilərik?
Scalability	Load on dəfə artanda cost və latency ilə nə baş verir?
Availability	Sistem vaxtın hansı hissəsində istifadəyə yararlıdır və outage-lər nə qədər davam edir?
Reliability	Partial failure daxil olmaqla, nəticələri ardıcıl olaraq düzgün verirmi?
Security	Kim nə edə bilər və biz bunu haradan bilirik?
Maintainability	Növbəti dəyişiklik, eləcə də yüzüncü dəyişiklik nəyə başa gəlir?
Deployability	"Merge olundu"dan "production-dadır"a qədər nə qədər vaxt keçir və bu nə dərəcədə risklidir?
Observability	Nəsə səhv gedəndə nəyin və niyə baş verdiyini nə qədər tez anlaya bilirik?
Testability	Production-a deploy etmədən əminlik qazana bilərikmi?
Cost	İşlətmək nəyə başa gəlir və istifadə artdıqca bu necə dəyişir?

Siyahı tam deyil. Regulatory compliance, portability, accessibility və data residency konkret domain-lərdə əhəmiyyət daşıyır. Məqsəd ortaq lüğətə malik olmaqdır ki, söhbət "yaxşı olmalıdır" əvəzinə bu sözlər üzərində getsin.

Qeyri-müəyyən attribute-lər faydasızdır

"Sistem scalable olmalıdır" cümləsi nə design üçün əsas ola bilər, nə test oluna bilər, nə də mübahisə mövzusu ola bilər. Standart həll sabit formaya malik quality attribute scenario-dur:

Source: şərti kim və ya nə trigger edir
Stimulus: nə baş verir
Environment: hansı şəraitdə (normal load, peak, degraded)
Artifact: sistemin hansı hissəsi təsirlənir
Response: sistem nə etməlidir
Measure: uğurlu olduğunu haradan biləcəyik

Bu formada yazılmış scalability scenario-su belə görünür:

Məhsulun launch-ının ilk saatında (environment) web client-lərdən (source) gələn traffic catalogue service-ə (artifact) qarşı saniyədə 500 request-dən 5 000 request-ə yüksəlir (stimulus). Service request-lərə xidmət göstərməyə davam edir (response), p99 latency 300 ms-dən aşağı qalır və heç bir manual müdaxilə tələb olunmur (measure).

İndi əleyhinə design edəcəyiniz, load test aparacağınız və kimsə onu pozacaq dəyişiklik təklif edəndə göstərə biləcəyiniz konkret bir şey var.

Onları mütləq sıralamalısınız

Hər attribute arzuolunandır. Məhz buna görə onları sadəcə sadalamaq kifayət deyil. Architecture sıradan doğur.

Faydalı məşq: məhsula sahib olan insanları bir otağa yığın və ilk beşini sıralamağa məcbur edin. Qiymətləndirmək yox, sıralamaq. "Availability consistency-dən üstündür" — bu, qərardır. "Hər ikisi vacibdir" — bu, məsuliyyətdən qaçmaqdır.

Dəfələrlə qarşılaşacağınız bəzi ziddiyyətlər:

Consistency vs. availability. Network partition zamanı hər ikisinə sahib ola bilməzsiniz. CAP teoremi tez-tez yanlış sitat gətirilir, amma praktik dərs qüvvədədir: hər data set üçün işlər pis gedəndə hansından imtina edəcəyinizi qərarlaşdırın.
Performance vs. maintainability. Cache-lər, denormalized cədvəllər və əllə tune edilmiş query path-lər sistemi həm daha sürətli, həm də dəyişməsi daha çətin edir.
Security vs. deployability. Release pipeline-dakı hər gate həm security control-dur, həm də deployment gecikməsidir.
Flexibility vs. simplicity. Configuration, plugin nöqtələri və abstraction layer-lər heç vaxt gəlməyə bilən gələcəklərə hazırlaşır və bu gün xərc çıxarır.

Prioritetlər haradan gəlir

Əvvəlki bölmə attribute-ləri sıralamağı tələb etdi. Təbii sual yaranır: hansı əsasla? Cavab budur ki, sıranı architect öz zövqünə görə seçmir. Sıra məhsulun öz vəziyyətindən çıxır və onu tapmaq üçün dörd sual vermək kifayətdir.

1. Pul nədən gəlir və nəyi itirmək olmaz? Bu, biznes modeli sualıdır. Payment şirkəti üçün itmiş bir write itmiş puldur, ona görə consistency və reliability siyahının başındadır. Sosial şəbəkə üçün isə itmiş bir like-ı heç kim fərq etməz, amma feed yavaş açılsa istifadəçilər gedər. Orada performance və availability öndədir.

2. Ən pis gün necə görünür? Özünüzdən soruşun: hansı outage xəbərlərə düşərdi? Bank üçün bu, müştərinin yanlış balans görməsidir. Bilet satışı üçün satış açılan dəqiqədə saytın çökməsidir. Cavab ən çox qorunmalı olan attribute-ü birbaşa göstərir.

3. Sistem nə qədər böyüyəcək? Əlli əməkdaşın istifadə etdiyi daxili alət üçün scalability demək olar ki, vacib deyil, maintainability və cost isə vacibdir. Milyonlarla istifadəçi gözləyən məhsul üçün scalability yuxarı qalxır. Burada bir xəbərdarlıq var: bu gün on istifadəçiniz varsa, on milyon üçün design etmək, gəlməyə bilən gələcək üçün indi pul ödəmək deməkdir.

4. Sistemi kim quracaq və kim işlədəcək? İki nəfərlik komanda mürəkkəb multi-region sistemi gecə saat üçdə təmir edə bilməz. Belə komanda üçün sadəlik və asan operate edilmə siyahıda yuxarı qalxır. Yalnız iki nəfərin başa düşdüyü sistem diaqram nə deyirsə desin, highly available deyil.

Eyni "sifariş vermək" feature-i bu suallara verilən cavablardan asılı olaraq fərqli sıra alır:

	Online bank	Daxili inventory aləti	Bilet satışı platforması
1-ci yer	Reliability	Maintainability	Scalability
2-ci yer	Security	Cost	Availability
3-cü yer	Availability	Deployability	Performance

Prioritet bu dörd mənbədən birinə bağlana bilmirsə, o, çox güman ki, kiminsə şəxsi seçimidir və onu yenidən müzakirə etmək lazımdır.

Architecture "-ility"lərin təqibi kimi

Quality attribute-lərin çoxunun ingilis dilində adı -ility ilə bitir: availability, scalability, maintainability, deployability. Ona görə mühəndislər onları qısaca "-ility"lər adlandırır.

Bölmənin əsas fikri sadədir: architecture-dakı hər struktur hansısa -ility-ni yaxşılaşdırmaq üçün oradadır. Belə struktura tactic deyilir, yəni konkret bir keyfiyyət məqsədinə çatmağın konkret vasitəsi. Bina ilə müqayisə etmək olar: qalın divar istiliyi saxlamaq üçün, geniş qapı əlçatanlıq üçün, yanğın pilləkəni təhlükəsizlik üçündür. Heç biri təsadüfən orada deyil.

Struktur	Hansı attribute-ə xidmət edir	Necə kömək edir	Qiyməti
Replication	Availability	Bir nüsxə xarab olanda digəri cavab verir	Əlavə xərc, nüsxələri sinxron saxlamaq çətinliyi
Caching	Performance	Tez-tez istənən cavab yaxında saxlanır	Köhnəlmiş data riski
Modular boundary-lər	Maintainability	Dəyişiklik bir module-un içində qalır	Əvvəlcədən düşünülmüş dizayn tələb edir
Queue	Reliability	Consumer dayananda producer işləməyə davam edir	Daha çox hərəkətli hissə, nəticə gec görünür

Son sütun vacibdir: hər tactic bir attribute-ü yaxşılaşdırır və adətən başqasını pisləşdirir. Əvvəlki bölmələrdəki ziddiyyətlər də buradan gəlir.

Bu modeli iki istiqamətdə işlətmək olar:

Yuxarıdan aşağı. Sıralanmış prioritet siyahınız var. Siyahının başındakı attribute-lər üçün tactic-lər seçirsiniz. Availability birinci yerdədirsə, replication və failover haqqında düşünürsünüz.
Aşağıdan yuxarı. Kimsə yeni struktur təklif edir. Soruşursunuz: bu hansı attribute-ə xidmət edir və o attribute bizim siyahımızda yuxarıdadırmı?

İkinci sualın cavabı yoxdursa, bu, xəbərdarlıq işarəsidir. Gündə yüz mesaj göndərən sistemə Kafka əlavə etmək və ya üç nəfərlik komanda üçün on microservice qurmaq "böyük şirkətlər belə edir" deyə seçilirsə, bu, cargo cult-dur: formanı təkrarlamaq, amma onu lazımlı edən problemin özü olmadan.

Bu düşüncə tərzi kitabın ikinci yarısında dəfələrlə qayıdır. Fəsil 6 attribute-ləri capacity rəqəmlərinə, Fəsil 7 availability-ni SLO-lara çevirir. Fəsil 9 və 11 isə tanış komponentləri və pattern-ləri məhz hansı attribute-ə xidmət etdikləri sualı ilə nəzərdən keçirir.

Hazırkı sisteminiz haqqında suallar

Sisteminizin ən vacib davranışı üçün bir quality attribute scenario yazın. Sabah test oluna bilərmi?
İlk beş attribute-nizi sıralayın. Hazırkı architecture sizin sıranızla razılaşırmı?
Sisteminizdə heç bir attribute ilə əlaqələndirə bilmədiyiniz bir struktur tapın. O niyə oradadır?