Buduj na dziś. Planuj na jutro. Planuj na awarię.

🌐 Dostępne także w 28 językach

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 5 z 7 w rozdziale Myśleć jak architekt danych, pierwszym rozdziale kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Architektura to sztuka kompromisów · Dalej: Poznaj swoje narzędzia: dziewięć pytań

Pytanie, na które odpowiada ten moduł: jak projektować pod dzisiejsze wymagania, planując jednocześnie wzrost i awarie?

Jeden z najłatwiejszych błędów w architekturze to projektowanie tylko pod wymagania, które masz przed sobą. Mamy projekt, backlog i wymagania. Budujemy coś, co je spełnia. Działa, więc ogłaszamy zwycięstwo. Pół roku później biznes się zmienia albo dane rosną, albo inny dział chce z tego korzystać, albo przejmujemy firmę, albo trzeba zintegrować nowy system, albo zawodzi coś, czego nikt nie przewidział.

Nic z tego nie powinno zaskakiwać architekta. Nie przewidzimy wszystkiego, co się wydarzy, ale możemy projektować ze świadomością, że coś się wydarzy. Dlatego patrzę na architekturę przez trzy soczewki:

Buduj na dziś. Planuj na jutro. Planuj na awarię.

Potrzebujesz wszystkich trzech.

Click to enlarge

Buduj na dziś

Architektura zaczyna się od problemu, który naprawdę mamy. Brzmi to oczywiście, ale architekci mogą popełnić błąd odwrotny do myślenia krótkoterminowego: możemy przeprojektować. A co, jeśli przejmiemy dwanaście firm, będziemy mieć miliard klientów, wejdziemy do 40 krajów, a każdy system będzie potrzebował integracji w czasie rzeczywistym? Może. Ale czy to realne możliwości, czy wymyślamy problemy? Architektura nie polega na budowaniu najbardziej wyrafinowanego systemu, jaki potrafimy sobie wyobrazić. Polega na budowaniu odpowiedniego.

Zacznij więc od dziś: czego potrzebuje biznes, jakie są rzeczywiste wolumeny, liczba użytkowników i transakcji, jak często dane się zmieniają i jak szybko muszą się przemieszczać, kto potrzebuje dostępu, skąd dane przychodzą i dokąd idą. I co najważniejsze: dlaczego? Te odpowiedzi dają nam coś konkretnego do zaprojektowania.

Szukaj wymagań domyślnych

Wymagania, które dostajesz, to niekoniecznie wszystkie wymagania, jakie masz. Niemal zawsze istnieją wymagania domyślne.

Biznes mówi: „Potrzebujemy danych klientów w Salesforce”. Dobrze. W takim razie ktoś musi być właścicielem tych danych i zdecydować, jak świeże muszą być. Musimy wiedzieć, co się dzieje, gdy system źródłowy nie działa, jak zauważymy, że synchronizacja zawiodła, i która strona wygrywa, gdy Salesforce i źródło się nie zgadzają. Potrzebujemy okresu retencji, modelu dostępu, decyzji w sprawie pól wrażliwych i sposobu poprawiania złych danych.

Nic z tego nie było w historyjce użytkownika. A wszystko to nadal jest architektura. Duża część stawania się architektem to nauka rozpoznawania pytań, których jeszcze nikt nie zadał.

Znaj swoje liczby

Ciągle naciskam na architektów, żeby podawali liczby. Nie mów mi, że danych jest dużo; powiedz, ile. Dziesięć tysięcy, dziesięć milionów, sto milionów, miliard? To bardzo różne architektury. Nie mów mi, że integracja uruchamia się często: co godzinę, co minutę, tysiąc razy na sekundę? Nie mów mi, że szybko rośniemy. Jak szybko?

Gdy nie mam lepszej liczby, moim punktem wyjścia jest 30 procent wzrostu rocznie. To nie prognoza; to wymuszenie. Jeśli ktoś mówi mi, że dziś mamy 10 milionów rekordów, nie chcę, żeby dyskusja zatrzymała się na 10 milionach. Przy 30 procentach rocznie w przyszłym roku będzie ich około 13 milionów, rok później 17 milionów, a jeszcze rok później około 22 milionów. Teraz porozmawiajmy o projekcie. Jeśli biznes mówi mi, że 30 procent to absurd, świetnie: podajcie mi prawdziwą liczbę. Chodzi o to, żeby wzrost stał się częścią dyskusji o architekturze.

Nazywam to Liczbą Zer Steve’a (Steve’s Number of Zeros). Jedno dodatkowe zero może całkowicie zmienić twoją architekturę. Dziesięć tysięcy, sto tysięcy, milion, dziesięć milionów, sto milionów: funkcja się nie zmieniła i wymaganie może się nie zmieniło, ale architektura może się zmienić.

Pamiętasz wizyty z modułu 1? Podstawmy prawdziwe liczby. Ponad 1200 lokalizacji, 100 wizyt na lokalizację dziennie, sześć dni w tygodniu, około 305 dni w roku. To ponad 36 milionów wizyt w pierwszym roku. Każda wizyta tworzy dwa rekordy, więc ponad 73 miliony rekordów. Teraz przechowuj historię z pięciu lat przy wzroście 30 procent rocznie i masz ponad 650 milionów rekordów. Ta sama funkcja, to samo wymaganie. Kilka zer więcej i zupełnie inna architektura.

Planuj na jutro

Gdy rozumiem dziś, patrzę w przyszłość: co ma realną szansę się zmienić? Wolumen jest częścią odpowiedzi, ale jutro to nie tylko więcej. Może też oznaczać inaczej: więcej produktów, działów i krajów; inne wymagania dotyczące prywatności; nowe kanały i integracje; fuzję albo przejęcie; nową strategię danych podstawowych albo platformę analityczną; agenta AI korzystającego z informacji, które zaprojektowano wyłącznie dla ludzi.

Dlatego tak mi zależy, żeby architektura mogła rosnąć przez dodawanie, a nie ciągłe przerabianie. Jeśli biznes doda produkt, czy model go przyjmie? Jeśli inny system będzie potrzebował danych, czy możemy je czysto udostępnić? Jeśli wolumen skoczy, czy mamy dokąd pójść? Jeśli struktura biznesu się zmieni, czy będziemy musieli rozebrać model danych na części? Nie próbujemy idealnie przewidzieć przyszłości. Próbujemy nie zapędzić się w kozi róg.

Nie buduj jutra już dziś

Tu też potrzebna jest równowaga. Planowanie na jutro nie oznacza budowania już dziś jutrzejszego systemu. Jeśli mamy 100 000 rekordów, a za pięć lat możemy mieć 100 milionów, nie znaczy to, że już teraz budujemy architekturę na 100 milionów rekordów. Może przynieść koszty i złożoność, których jeszcze nie potrzebujemy.

Pytanie, na które chcę znać odpowiedź, brzmi: czy dzisiejsza architektura może przekształcić się w jutrzejszą? Jeśli możemy zacząć prosto, mając jasną drogę naprzód, to często lepsze niż płacenie za złożoność lata wcześniej. Niebezpieczne nie jest zaczynanie od małego. Niebezpieczne jest zaczynanie w miejscu, z którego nie ma dokąd pójść.

Planuj na awarię

Teraz część, o której nikt nie lubi rozmawiać: rzeczy się psują. Nigdy nie zaprojektowałem systemu, w którym każdy komponent byłby dostępny zawsze, każda integracja by się udawała, każdy użytkownik wprowadzał idealne dane, a każdy zewnętrzny system zachowywał się dokładnie tak, jak opisano w dokumentacji. Nie projektuj więc takiego systemu.

Zapytaj, co może zawieść, a potem zapytaj, co się stanie, gdy to zawiedzie. Integracja przekracza limit czasu. API odrzuca żądanie. Nocny import przetwarza 800 000 rekordów i zawodzi przy 200 000. System źródłowy przestaje działać. Użytkownik wprowadza nieprawidłowe dane. Zewnętrzny identyfikator pojawia się dwa razy. System wyżej w łańcuchu zmienia format wartości bez zmiany nazwy pola. Proces udaje się w jednym systemie, a zawodzi w drugim. To nie są nietypowe przypadki brzegowe. Tak wygląda produkcja.

Częściowy sukces to wciąż awaria, którą trzeba zrozumieć

Częściowe awarie są szczególnie niebezpieczne w architekturze danych. Wyobraź sobie przenoszenie miliona rekordów i proces, który raportuje, że się zakończył. Świetnie. Ale czy dotarł milion, czy 999 997, i których trzech brakuje? Może 200 000 się nie powiodło, niektóre utworzono dwa razy albo wszystkie dotarły, a części pól nie udało się przekształcić.

„Zadanie zakończone” to nie to samo co dane są poprawne. Architekt danych myśli o uzgadnianiu: skąd wiemy, co powinno się wydarzyć, co wydarzyło się naprawdę i jaka jest różnica? I co z tym zrobimy?

Oto co robię, gdy systemy stają się złożone. Rekordy idą z A do B, od lewej do prawej. Potem B odsyła coś z powrotem: potwierdzenie dla każdego rekordu, który otrzymał i zapisał. Teraz A może porównać to, co wysłał, z tym, co zostało potwierdzone. Jeśli każdy rekord ma potwierdzenie, przebieg się udał. Jeśli brakuje jakichkolwiek potwierdzeń, nie udał się, bez względu na to, co mówi status zadania, i wiemy dokładnie, którymi rekordami się zająć: ponowić je, przekazać człowiekowi albo podnieść alarm.

Click to enlarge

Zawodź z gracją

Kiedy dochodzi do awarii, chcę wiedzieć, co system robi dalej: czy ponawia próbę, automatycznie czy nie; co się stanie, jeśli ta sama transakcja zostanie przetworzona dwa razy; dokąd trafiają rekordy, które się nie powiodły, i czy dobre rekordy płyną dalej obok złego; kto dostaje alarm, z jakimi informacjami i jak odtwarza awarię; i jak użytkownik dowiaduje się, że coś poszło nie tak.

I co najważniejsze: czy możemy wrócić do działania, nie pogarszając problemu? Strategia ponawiania, która tworzy zduplikowane dane, nie jest dobrą strategią odzyskiwania. Dobra architektura zakłada awarię i daje nam drogę powrotu.

Monitoruj to, co ważne

Planowanie na awarię bez monitorowania to nie jest prawdziwe planowanie. Jeśli integracja zawodzi o 2:00 w nocy i nikt tego nie zauważa, dopóki trzy dni później nie zadzwoni klient, nie mieliśmy architektury operacyjnej. Mieliśmy nadzieję.

Zdecyduj, co musi być widoczne: czy proces się uruchomił, ile trwał, ile rekordów przetworzył, ile się udało, a ile nie? Czy wolumeny nagle odbiegają od normy? Czy rośnie zaległość, czy przybywa błędów? Architektura nie kończy się, gdy wdrożenie się powiedzie. Ktoś jutro musi ten system obsługiwać, a to też jest część projektu.

Myśl we wszystkich trzech kierunkach

Stosuj trzy soczewki przez resztę tego kursu. Gdy projektujemy model danych: czy działa dziś, czy może rosnąć jutro i co się stanie, gdy dane będą złe albo niepełne? Integrację: czy przenosi dzisiejsze dane, czy poradzi sobie z jutrzejszym wolumenem i systemami i co się stanie, gdy jedna strona nie działa? Duże wolumeny danych: co mamy dziś, dokąd zmierzają liczby i jak wrócimy do działania, gdy duża operacja uda się tylko częściowo?

Technologia zmienia się z rozdziału na rozdział. Pytania nie.

Architektura istnieje w czasie

Programista może czasem spojrzeć na wymaganie i zapytać: „Czy to działa?”. Architekt musi zapytać o więcej: czy działa dziś, czy będzie działać jutro i co się stanie, gdy w ogóle przestanie działać? Te trzy pytania wyprowadzają nas poza implementację, w życie systemu.

Nie przewidzisz każdego przyszłego wymagania ani nie zapobiegniesz każdej awarii. To nie jest cel. Celem jest zbudowanie czegoś odpowiedniego do tego, co wiemy dziś, zostawienie sobie drogi na jutro i posiadanie planu na chwilę, gdy rzeczywistość nie będzie współpracować.

Buduj na dziś. Planuj na jutro. Planuj na awarię. Będziemy używać tych trzech soczewek raz po raz.

Co tu decyduje architekt

• Jakie są rzeczywiste wolumeny i wzrost oraz które liczby zmieniłyby projekt.
• Jakich domyślnych wymagań biznes jeszcze nie wypowiedział.
• Jak dzisiejszy projekt może przekształcić się w jutrzejszy, bez budowania jutrzejszego systemu już dziś.
• Co się dzieje, gdy coś zawiedzie: odzyskiwanie, uzgadnianie i monitorowanie.