לבנות להיום. לתכנן למחר. לתכנן לכישלון.

🌐 זמין גם ב-28 שפות

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

התמונה נוצרה בבינה מלאכותית

תורגם בבינה מלאכותית. הקהילה עוד לא בדקה את התרגום. לקריאה באנגלית

יחידה 5 מתוך 7 בפרק לחשוב כמו ארכיטקט נתונים, הפרק הראשון בקורס Data Architect. כל יחידה עומדת בפני עצמה. הקודם: ארכיטקטורה היא אמנות הפשרות · הבא: הכירו את הכלים שלכם: תשע השאלות

השאלה שהיחידה הזו עונה עליה: איך מתכננים לדרישות של היום ובמקביל מתכננים לצמיחה ולכישלון?

אחת הטעויות הכי קלות בארכיטקטורה היא לתכנן רק לדרישות שמונחות מולכם. יש לנו פרויקט, backlog ודרישות. אנחנו בונים משהו שעומד בהן. זה עובד, ואנחנו מכריזים על ניצחון. חצי שנה אחר כך העסק משתנה, או שהנתונים גדלים, או שיחידה עסקית אחרת רוצה להשתמש בזה, או שאנחנו רוכשים חברה, או שמערכת חדשה צריכה להשתלב, או שמשהו נכשל ואף אחד לא תכנן את זה.

שום דבר מזה לא אמור להפתיע ארכיטקט. אנחנו לא יכולים לחזות כל מה שיקרה, אבל אנחנו יכולים לתכנן מתוך ידיעה שמשהו יקרה. בגלל זה אני מסתכל על ארכיטקטורה דרך שלוש עדשות:

לבנות להיום. לתכנן למחר. לתכנן לכישלון.

אתם צריכים את שלושתן.

Click to enlarge

לבנות להיום

ארכיטקטורה מתחילה מהבעיה שבאמת יש לנו. זה נשמע מובן מאליו, אבל ארכיטקטים יכולים לעשות את הטעות ההפוכה לחשיבה קצרת טווח: אנחנו יכולים לתכנן יותר מדי (over-architect). מה אם נרכוש שתים-עשרה חברות, יהיה לנו מיליארד לקוחות, נתרחב ל-40 מדינות, וכל מערכת תצטרך אינטגרציה בזמן אמת? אולי. אבל האם אלה אפשרויות אמיתיות, או שאנחנו ממציאים בעיות? ארכיטקטורה היא לא בניית המערכת הכי מתוחכמת שאפשר לדמיין. היא בניית המערכת המתאימה.

אז התחילו מהיום: מה העסק צריך, הנפחים, המשתמשים והטרנזקציות בפועל, באיזו תדירות הנתונים משתנים וכמה מהר הם צריכים לנוע, מי צריך גישה, ומאיפה הנתונים מגיעים ולאן הם הולכים. והכי חשוב: למה? התשובות האלה נותנות לנו משהו קונקרטי לתכנן.

חפשו את הדרישות המשתמעות

הדרישות שקיבלתם הן לא בהכרח כל הדרישות שיש לכם. כמעט תמיד יש דרישות משתמעות.

העסק אומר: “אנחנו צריכים נתוני לקוחות ב-Salesforce.” בסדר. אז מישהו צריך להיות הבעלים של הנתונים האלה ולהחליט כמה עדכניים הם חייבים להיות. אנחנו צריכים לדעת מה קורה כשמערכת המקור למטה, איך נשים לב כשסנכרון נכשל, ואיזה צד גובר כש-Salesforce והמקור לא מסכימים. אנחנו צריכים תקופת שמירה, מודל גישה, החלטה לגבי שדות רגישים, ודרך לתקן נתונים שגויים.

שום דבר מזה לא היה ב-user story. כל זה עדיין ארכיטקטורה. חלק גדול מלהפוך לארכיטקט הוא ללמוד לזהות את השאלות שעוד לא נשאלו.

הכירו את המספרים שלכם

אני כל הזמן דוחף ארכיטקטים לכמת. אל תגידו לי שיש הרבה נתונים; תגידו לי כמה. עשרת אלפים, עשרה מיליון, מאה מיליון, מיליארד? אלה ארכיטקטורות שונות מאוד. אל תגידו לי שהאינטגרציה רצה לעיתים קרובות: כל שעה, כל דקה, אלף פעמים בשנייה? אל תגידו לי שאנחנו גדלים מהר. כמה מהר?

כשאין לי מספר טוב יותר, נקודת הבסיס שלי היא 30 אחוז צמיחה בשנה. זו לא תחזית; זה כלי שמכריח אותנו לחשוב. אם מישהו אומר לי שיש לנו היום 10 מיליון רשומות, אני לא רוצה שהדיון ייעצר ב-10 מיליון. ב-30 אחוז בשנה נגיע לבערך 13 מיליון בשנה הבאה, 17 מיליון בשנה שאחריה, ובערך 22 מיליון בשנה שאחרי זה. עכשיו בואו נדבר על התכנון. אם העסק אומר לי ש-30 אחוז זה מגוחך, מצוין: תנו לי את המספר האמיתי. הנקודה היא להפוך את הצמיחה לחלק מהדיון הארכיטקטוני.

אני קורא לזה “מספר האפסים” של Steve (Steve’s Number of Zeros). אפס אחד נוסף יכול לשנות לגמרי את הארכיטקטורה שלכם. עשרת אלפים, מאה אלף, מיליון, עשרה מיליון, מאה מיליון: הפיצ’ר לא השתנה, ואולי גם הדרישה לא השתנתה, אבל הארכיטקטורה עשויה להשתנות.

זוכרים את התורים מיחידה 1? בואו נשים עליהם את המספרים האמיתיים. יותר מ-1,200 סניפים, 100 תורים לסניף ביום, שישה ימים בשבוע, בערך 305 ימים בשנה. זה יותר מ-36 מיליון תורים בשנה הראשונה. כל ביקור יוצר שתי רשומות, אז יותר מ-73 מיליון רשומות. עכשיו שמרו חמש שנים של היסטוריה, עם צמיחה של 30 אחוז בשנה, ומגיעים ליותר מ-650 מיליון רשומות. אותו פיצ’ר, אותה דרישה. עוד כמה אפסים, וארכיטקטורה שונה לגמרי.

לתכנן למחר

ברגע שאני מבין את היום, אני מסתכל קדימה: מה סביר שישתנה? הנפח הוא חלק מזה, אבל מחר זה לא רק יותר. זה יכול להיות גם אחר: יותר מוצרים, יחידות עסקיות ומדינות; דרישות פרטיות שונות; ערוצים ואינטגרציות חדשים; מיזוג או רכישה; אסטרטגיית נתוני אב חדשה או פלטפורמת אנליטיקה חדשה; סוכן בינה מלאכותית שצורך מידע שתוכנן רק לבני אדם.

בגלל זה כל כך חשוב לי אם הארכיטקטורה יכולה לגדול דרך הוספה ולא דרך שינוי מתמיד. אם העסק מוסיף מוצר, המודל יכול לקלוט אותו? אם מערכת אחרת צריכה את הנתונים, אפשר לחשוף אותם בצורה נקייה? אם הנפח קופץ, יש לנו לאן ללכת? אם המבנה העסקי משתנה, נצטרך לפרק את מודל הנתונים? אנחנו לא מנסים לחזות את העתיד בצורה מושלמת. אנחנו מנסים לא לצבוע את עצמנו לפינה.

אל תבנו את המחר היום

יש כאן איזון. לתכנן למחר לא אומר לבנות היום את המערכת של מחר. אם יש לנו 100,000 רשומות ואולי יהיו לנו 100 מיליון בעוד חמש שנים, זה לא אומר שאנחנו בונים עכשיו את הארכיטקטורה של 100 מיליון רשומות. היא עלולה להביא עלות ומורכבות שאנחנו עוד לא צריכים.

השאלה שאני רוצה תשובה עליה היא: האם הארכיטקטורה של היום יכולה להתפתח לארכיטקטורה של מחר? אם אפשר להתחיל בפשטות עם דרך ברורה קדימה, זה לרוב עדיף על פני תשלום מחיר המורכבות שנים מוקדם מדי. הסכנה היא לא להתחיל בקטן. הסכנה היא להתחיל במקום שאין ממנו לאן ללכת.

לתכנן לכישלון

עכשיו החלק שאף אחד לא אוהב לדבר עליו: דברים נכשלים. מעולם לא תכננתי מערכת שבה כל רכיב נשאר זמין לנצח, כל אינטגרציה הצליחה, כל משתמש הזין נתונים מושלמים, וכל מערכת חיצונית התנהגה בדיוק כמו שתועד. אז אל תתכננו מערכת כזו.

שאלו מה יכול להיכשל, ואז שאלו מה קורה כשזה קורה. אינטגרציה נתקלת ב-timeout. API דוחה בקשה. טעינה לילית מעבדת 800,000 רשומות ונכשלת ב-200,000. מערכת מקור נופלת. משתמש מזין נתונים לא תקינים. מזהה חיצוני מופיע פעמיים. מערכת במעלה הזרם משנה את הפורמט של ערך בלי לשנות את שם השדה. תהליך מצליח במערכת אחת ונכשל באחרת. אלה לא מקרי קצה חריגים. ככה נראית סביבת ייצור.

הצלחה חלקית היא עדיין כישלון שצריך להבין

כישלונות חלקיים מסוכנים במיוחד בארכיטקטורת נתונים. דמיינו שאתם מעבירים מיליון רשומות, והתהליך מדווח שהוא הסתיים. מצוין. אבל האם הגיע מיליון, או 999,997, ואילו שלוש חסרות? אולי 200,000 נכשלו, חלק נוצרו פעמיים, או שהכול הגיע וחלק מהשדות נכשלו בהמרה.

“המשימה הסתיימה” זה לא אותו דבר כמו הנתונים נכונים. ארכיטקט נתונים חושב על התאמה (reconciliation): איך אנחנו יודעים מה היה אמור לקרות, מה קרה בפועל, ומה ההפרש? ומה אנחנו עושים לגבי זה?

הנה מה שאני עושה כשהמערכות נעשות מורכבות. רשומות עוברות מ-A ל-B, משמאל לימין. ואז B שולח משהו בחזרה: אישור לכל רשומה שהוא קיבל ושמר. עכשיו A יכול להשוות בין מה ששלח לבין מה שאושר. אם לכל רשומה יש את האישור שלה, הריצה הצליחה. אם חסרים אישורים כלשהם, היא לא הצליחה, לא משנה מה סטטוס המשימה אומר, ואנחנו יודעים בדיוק אחרי אילו רשומות ללכת: לנסות אותן שוב, להעביר אותן לאדם, או להתריע.

Click to enlarge

להיכשל בחן

כשכישלון קורה, אני רוצה לדעת מה המערכת עושה אחר כך: האם היא מנסה שוב, ואם כן, אוטומטית או לא; מה קורה אם אותה טרנזקציה מעובדת פעמיים; לאן הולכות רשומות שנכשלו, והאם רשומות תקינות ממשיכות לזרום ולעקוף רשומה פגומה; מי מקבל התראה, עם איזה מידע, ואיך מריצים מחדש את מה שנכשל; ואיך משתמש מגלה שמשהו השתבש.

והכי חשוב: האם אפשר להתאושש בלי להחמיר את הבעיה? אסטרטגיית ניסיון חוזר שיוצרת נתונים כפולים היא לא ממש אסטרטגיית התאוששות. ארכיטקטורה טובה מניחה שיהיה כישלון ונותנת לנו דרך חזרה.

נטרו את מה שחשוב

לתכנן לכישלון בלי ניטור זה לא באמת תכנון. אם אינטגרציה נכשלת ב-02:00 בלילה ואף אחד לא שם לב עד שלקוח מתקשר שלושה ימים אחר כך, לא הייתה לנו ארכיטקטורה תפעולית. הייתה לנו תקווה.

החליטו מה צריך להיות ניתן לצפייה: האם התהליך רץ, כמה זמן הוא לקח, כמה רשומות עובדו, כמה הצליחו וכמה נכשלו? האם הנפחים פתאום שונים מהרגיל? האם ה-backlog גדל, האם השגיאות עולות? הארכיטקטורה לא נגמרת כשהפריסה מצליחה. מישהו צריך לתפעל את המערכת הזו מחר, וזה חלק מהתכנון.

לחשוב בשלושת הכיוונים

המשיכו להפעיל את שלוש העדשות לאורך שאר הקורס. כשאנחנו מתכננים מודל נתונים: האם הוא עובד היום, האם הוא יכול לגדול מחר, ומה קורה כשהנתונים שגויים או חסרים? אינטגרציה: האם היא מעבירה את הנתונים של היום, האם היא יכולה להתמודד עם הנפחים והמערכות של מחר, ומה קורה כשאחד הצדדים למטה? נפחי נתונים גדולים: מה יש לנו היום, לאן המספרים הולכים, ואיך מתאוששים כשפעולה גדולה מצליחה רק בחלקה?

הטכנולוגיה משתנה מפרק לפרק. השאלות לא.

ארכיטקטורה קיימת לאורך זמן

מפתח יכול לפעמים להסתכל על דרישה ולשאול: “זה עובד?” הארכיטקט צריך לשאול יותר: האם זה עובד היום, האם זה עדיין יעבוד מחר, ומה קורה כשזה לא עובד בכלל? שלוש השאלות האלה לוקחות אותנו מעבר למימוש ואל תוך החיים של המערכת.

לא תחזו כל דרישה עתידית ולא תמנעו כל כישלון. זו לא המטרה. המטרה היא לבנות משהו שמתאים למה שאנחנו יודעים היום, להשאיר לעצמנו לאן ללכת מחר, ולהחזיק תוכנית למקרה שהמציאות לא משתפת פעולה.

לבנות להיום. לתכנן למחר. לתכנן לכישלון. נשתמש בשלוש העדשות האלה שוב ושוב.

מה הארכיטקט מחליט כאן

• מהם הנפחים והצמיחה האמיתיים, ואילו מספרים היו משנים את התכנון.
• אילו דרישות משתמעות העסק עוד לא אמר.
• איך התכנון של היום יכול להתפתח לתכנון של מחר, בלי לבנות היום את המערכת של מחר.
• מה קורה כשמשהו נכשל: התאוששות, התאמה וניטור.