Monitoring: מבוא ל Graphite ושימוש ב Time-Series

Graphite היא מערכת Open Source פופולארית למדי לניטור (Monitoring).
בצורה המקוצרת ביותר, היא מבצעת 2 פעולות בסיסיות:

• אוספת מספרים שמשתנים לאורך זמן (להלן "time-series").
• מציגה אותם כגרף.

המערכת מבוססת על עקרונות פשוטים למדי, ומסוגלת לטפל במליוני data points בשנייה.

Graphite זכתה לאימוץ נרחב בתעשייה, ככלי Monitoring חשוב. רבים משתמשים בה (ומספרים על זה): Github, Etsy, אובר, Electronic Arts, ועוד.

הקהילה הגדולה הרחיבה את Graphite עם מרחב של פונקציות סטטיסטיות בעזרתן ניתן להגדיר את הגרפים: החל מממוצע או median, דרך ניתוח אחוזונים או סטיית תקן, ועד אלגוריתמים לחיזוי מסוג Holt-Winters.

 מצד שני - צצו גם תלונות שונות על המערכת:

• ניהול הנתונים כקבצים אינו יעיל כאשר מתשאלים הרבה מטריקות (metrics) במקביל. בהמשך נראה שזה מצב כמעט ובלתי נמנע...
• ה UI הוא לא כ"כ יפה...
• יש פונקציונליות חסרה, למשל: aggregation של נתונים, alerts, וגילוי אנומליות...
• ההתקנה של Graphite היא לא פשוטה (הרבה תלויות), והתפעול השוטף שלה - גם עשוי להיות לא כ"כ פשוט.

מכיוון ש Graphite היא מערכת המורכבת ממודולים נפרדים עם APIs מוגדרים היטב - הצרכנים שהתלוננו פשוט החליפו חלקים שונים במערכת. בלי לשם לב, נוצרה אסופה גדולה של מודולים להחלפה, כאשר ה APIs שהגדירה Graphite  - הפכו לסוג של "סטנדרט" בתעשייה, אליו מתממשקים כלים רבים.


כיום כבר ניתן לראות הרבה תצורות בהן החליפו חלק מהרכיבים של ה "Graphite Stack", ואפילו תצורות ללא אף אחד מהרכיבים המקוריים. Graphite הוא עדיין אחד כלי ה Monitoring הנפוצים ביותר שקיימים.


אם אתם קוראים אדוקים של הבלוג, אתם בוודאי יודעים שאני מאוד אוהב כלי Monitoring בשם New Relic- בעבר כתבתי עליו פוסט.

מה הטעם להשתמש ב Graphite כאשר יש לנו כלי monitoring נהדר כמו New Relic?

1. New Relic הוא כלי יקר [א], וייתכן שיש מערכות שלא משתלם לשלם עבורן את ה premium של New Relic.
2. New Relic מגיש סט מאוד שימושי של מדדים וניתוחים, אבל לעתים אנו רוצים מדדים ש New Relic לא מספק.
1. דוגמה קלאסית: מדדים עסקיים.
   בעולם של Gett: כמה הזמנות יש, כמה נהגים פנויים, כמה נוסעים שממתינים למונית כבר רבע שעה?
2. ב New Relic קיימת פונקציונליות שדומה ל Graphite (עבור מערכות שמנוטרות ברישיון).
   New Relic מקשר את הנתונים בצורה קשיחה לאפליקציה, מה שעלול להקשות. אנחנו במקרה מסוים עזבנו אותו בנקודה זו לטובת Graphite, אם כי לא התאמצנו יותר מדי להשתמש בו. ייתכן ויש לזה פתרון.

Graphana - ה Dashboard ה"חם" בעולם ה Graphite כיום.

הארכיטקטורה של Graphite

בצורה פשטנית משהו, ניתן לתאר את הארכיטקטורה של Graphite בצורה הבאה:

• ניתן לזהות ב Graphite שלושה רכיבי-על מרכזיים: whisper, carbon ו graphite-web.
• המערכת (Application) שולחת נתונים של מטריקות (metrics) שונות ל carbon מעל tcp (פורט ברירת-מחדל: 2003).
• הפורמט בו מועברים הנתונים הוא מאוד פשוט: some metric name : some value : timestamp.
• קרבון שומר את הנתונים בבסיס הנתונים whisper, בסיס נתונים שמבוסס על קבצים ודומה לכלי ישן, יחסית, שנקרא RRD [ב].
• whisper מנהל קובץ נפרד לכל מטריקה, הוא למעשה סוג של Time Series Database (פרטים בהמשך).
• Graphite-web יודע לקבל קריאת GET (בעזרת endpoint בשם render/) כשהפרמטרים על ה URL מתארים query על מטריקה או מספר מטריקות.
• למשל: הפרמטר הבא סוכם את כמות ה logins היומית:

target=summarize(my.metric.logins, "1d")

• Graphite-web מרנדר PNG אותו הוא מגיש לדפדפן.
  הערה: זהו אלמנט של חוסר יעילות: היום קל יותר לקבל נתונים ולרנדר אותם ב javaScript - כך גם העבודה מתפזרת בין ה clients השונים.

Graphite כתובה ב Python, כאשר carbon ממומש ע"ג twisted (שהוא framework ל event-driven I/O) ו graphite-web כתוב ב django - ספריית MVC מפורסמת שדומה באופייה ל Rails.

Time Series Databases (להלן TSDB)

בשלב זה, ולפני שאנו צוללים לתמונת-מבט עמוקה יותר על הארכיטקטורה של Graphite, כדאי להבין מהם time-series - מכיוון שהם נמצאים בבסיסה של הארכיטקטורה של Graphite.

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

1. לדחוס את הנתונים בצורה יעילה יותר.
2. איתור מגמות (trends), מחזורים (cyclical fluctuation), ועונתיות (seasonal fluctuation) בנתונים.
3. לנתח חריגות בנתונים (אנומליות).
4. לנסות לחזות את המשך הסדרה.
5. להיות מסוגלים לחשב (בדיוק כזה או אחר) את ההסתברות להתנהגויות עתידיות של הסדרה. למשל: הסבירות לקטסטרופה עתידית.

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

מקור: Sabbir Rehman

בסיסי נתונים רלציוניים (או KV/Document) מסוגלים בהחלט לנהל סדרות עתיות, במיוחד כאשר הם רצים על חומרה עם SSD (שמספקת ביצועים טובים בהרבה מדיסק מכאני לגישות אקראיות רבות).


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

• ניצור טבלה לכל מדד (למשל: צריכת זכרון של שרת A, צריכת זכרון של שרת B, כמות פעולות IO של שרת A,... וכו')
• בכל טבלה יהיו שתי עמודות: זמן, וערך המדד.

כאשר יש לנו *הרבה* נתונים (מה שקורה לעתים קרובות ב Monitoring), ניתן לבצע אחת מ-2 אופטימיזציות מקובלות:

1. ליצור טבלה לא רק לכל מדד, אלא גם לכל מדד וטווח זמן - למשל מדד + תאריך (יום מסוים). כל יום יהיה טבלה חדשה.
1. אם הטבלה מייצגת תאריך - אז שדה הזמן יכול עתה להיות מצומצם לשעה ביום (ברזולוציה הנדרשת: שניות או מילי-שניות, למשל), וכך לחסוך מקום רב של אכסון, בעיקר באינדקסים.
2. התוצאה כמובן יכולה להיות שבמערכת יהיו לנו מאות או אלפי טבלאות שונות.
3. לרוב מקובל לשמור את הערכים לטווח מוגדר (נאמר: 30 יום), ולמחוק טבלאות ישנות יותר.
2. לצמצם את מספר השורות ע"י אכסון של טווח ערכים בכל שורה. למשל: יש לנו הרבה מדידות בשנייה (או בדקה), ואנו הופכים את הסכמה של כל שורה להיות: זמן, כמות דגימות, ממוצע דגימות, פיזור דגימות, ערך מקסימום, ערך מינימום ו BLOB עם כל ערכי הדגימות הספציפיים ומרכיב הזמן המתאים (שניה או מילי-שניה).
1. אם עבור הרוב הגדול של השאילתות הרזולוציה אליה צמצמנו את הנתונים (נאמר: דקה) היא מספיק טובה, אז רוב השאילתות יוכלו לרוץ על סיכמוי הביניים (למשל: "ממוצע דגימות" ו "כמות דגימות") - מה שירוץ הרבה יותר מהר.
1. צמצום שמצדיק את הטרחה הוא לרוב צמצום של כמה עשרות או מאות ערכים שונים או יותר - לתוך שורה בודדת.
2. אם נרצה לגשת לכל הערכים המדויקים (כנראה שנרצה לעשות זאת ברזולוציה קטנה, למשל - כמה דקות) - כל הנתונים עדיים שם. לא יצרנו איבוד מידע.

דוגמה לדחיסה של נתוני סדרה עתית לרשומה / אובייקט יחיד. מקור: O'Rielly, באדיבות MapR.

כמובן שבמקום לנהל את הסדרה העתית בעצמנו - ניתן לבחור בבסיס נתונים שזו ההתמחות שלהם (ועושים בערך מה שתיארנו למעלה). בסיסי הנתונים העתיים המדוברים ביותר כיום הם:

• Splunk (מוצר proprietary)
• משמש בעיקר לאינדוקס וניתוח נתונים (לא ממש monitoring), יותר נכון להשוות אותו ל ELK Stack מאשר ל Graphite Stack (למרות שהוא נחשב מוצר TSDB).
• InfluxDB (כתוב ב Go, יכול לחבר אותו ל Storage Engines שונים כמו LevelDB או RockDB).
• ניתן לאפיין אותו בפשטות התקנה / תפעול. הוא מתיימר להחליף את כל ה Graphite Stack בעתיד, ובנוסף הוא תומך במודל של time-events, שהוא רחב יותר ממודל ה time-series הקלאסי (מה שבא קצת על חשבון יעילות אכסון וביצועים). אולי שווה להקדיש לו פוסט בעתיד...
• OpenTSDB (הממומש מעל Hadoop HBase)
• ניתן לאפיין אותו ביכולת לטפל בכמויות גדולות מאוד של נתונים, ובמהירות. הוא מהיר בסדר גודל מ InfluxDB - כאשר כמות הנתונים גדולה מאוד.

TSDB כוללים לרוב עוד כמה פונקציות מסביב למודל של סדרות עתיות:

• downsampling - היכולת לשלוף נתונים ביעילות ברזולוציה קטנה יותר מזו שנשמרה (למשל: אנו שומרים מדד כל שניה, אך רוצים לשלוף את הערכים של פעם בחמש דקות).
• ביצוע פעולות השוואה / חישוב בין סדרות עתיות שונות, או מקטעים שונים באותה סדרה עתית. למשל: מה ההבדל בין התנהגות המדד היום, להתנהגותו באותו היום - לפני שבוע?
• אינדוקס הערכים ושליפה מהירה שלהם. למשל: שלוף את כל מקטעי הזמן בחודש האחרון בהם ה CPU utilization היה גבוה מ 70% - בצורה יעילה (ובהנחה שזה אירוע דיי נדיר).

סה"כ TSDBs כוללים tradeoff מאוד ברור: מודל נתונים פשוט ובסיסי של סדרות עתיות, עבורן ה TSDB יעיל בצורה לא-רגילה.

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

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

סיכום

בפוסט זה הכרנו את Graphite, כלי (או אולי Stack) טכנולוגיות פופולארי מאוד, בקוד פתוח - לניטור מערכות. הכח שלו - הוא ביכולת ה customization: ניתן להשתמש בו ל System Monitoring, ל Application Monitoring ואף ל Business Performance Monitoring. הבסיס שלו הוא דיי פשוט ויעיל - מה שתרם לפופולאריות הרבה שלו.

תמונת הארכיטקטורה שהצגתי היא פשטנית, ואנסה לכתוב פוסט המשך בו אסביר קצת יותר על Graphite, כיצד הוא עובד, ועם אילו בעיות / trade-offs יש להתמודד עם סוג כזה של מערכת.

בינתיים, אתם יכולים לגשת ל-2 הלינקים העוסקים בארכיטקטורה למטה - הם לא-רעים.


שיהיה בהצלחה!

----

[א] ע"פ מקורות זרים: כ 100$ לחודש לשרת. ע"פ מקורות זרים: ניתן להוריד את המחיר הנ"ל לבערך חצי - אם אתם צרכנים כבדים (יש לכם מאות שרתים מנוטרים). מה המחיר לאלפים? לרוב אם יש לכם יותר מכמה מאות שרתים - אתם לא תשלמו כבר ל NR, אלא תשתמשו ב open source כמו nagios עם הרחבות שלכם...

[ב] RRD הוא קיצור של Round Robin Database - על שם כך ששמר על קבצים בגודל קבוע בדיסק, ועשה שימוש חוזר בשטח שלהם.


----

לינקים רלוונטיים


רשימת כלי 3rd-party שעובדים עם Graphite:
http://graphite.readthedocs.org/en/latest/tools.html


הארכיטקטורה של Graphite, כפי שמתוארת ע"י היוצר שלה, כריס דיוויס:
http://aosabook.org/en/graphite.html
תיאור טוב ממקור אחר:
https://grey-boundary.io/the-architecture-of-clustering-graphite/


דרכים למימוש סדרות עתיות על גבי בסיס נתונים רלציוני:
https://academy.datastax.com/demos/getting-started-time-series-data-modeling
http://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql


ספר מבית O'Reilly על TSDB, ו openTSDB בעיקר. ניתן לקבל בחינם במימון MapR (שמשקיעה ב OpenTSDB):
https://www.mapr.com/time-series-databases-new-ways-store-and-access-data

השוואה של 10 TSDBs:
https://blog.outlyer.com/top10-open-source-time-series-databases


Splunk vs. ELK
https://riskfocus.com/splunk-vs-elk-part-1-cost/ (והמשכים...)

Elastic Search as a Time-Series datastore:
https://www.elastic.co/blog/elasticsearch-as-a-time-series-data-store

7 ההרגלים של אנשי תוכנה אפקטיביים במיוחד (חלק ב)

זהו פוסט המשך לפוסט 7 ההרגלים של אנשי תוכנה אפקטיביים במיוחד! (חלק א)
הפוסט עוקב אחר ספר, מאוד פופולארי, שעוזר להגדיר מה עוזר לאנשים מסוימים להיות אפקטיביים, בסדר גודל - יותר מאנשים אחרים.

הרגל שלישי: עשה ראשית את הדברים החשובים (AKA איזון בין חשוב ודחוף)

אנשים רבים בתעשיית התוכנה "מכורים לדחוף"  (urgent).

• עניינים דחופים הם בולטים וברורים יותר.
• יש משהו מרגש בלעשות משהו בלחץ זמן.
• פתרון דברים דחופים - מוביל להכרה מיידית.
• "אני עובד טוב יותר תחת לחץ"

נחלק את סוגי המשימות שיש בידנו ל-4 רבעים:

רובנו, נוטים להשקיע את עיקר זמננו ברביע של הדברים החשובים והדחופים (רביע I).

כמו כן ישנן שיטות שונות לניהול זמן, שרובן מתנהל בד"כ כך:

• נגדיר את כל הדברים שעלי לעשות
• נסדר אותם ע"פ סדר חשיבות
• נבצע ע"פ הסדר (בלי לסטות הרבה) ו"ננקה את הרשימה".

משהו ששיטות אלו מפספסות, הוא שסידור משימות ע"פ "סדר עדיפות" - יגרור אותנו שוב ושוב להתמקד בדברים החשובים והדחופים.


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

ההסבר לכך הוא כזה:

• השינויים המהותיים ביותר - דורשים בד"כ עבודה ארוכת טווח. שינויים שכאלה לא נוטים להתפס כדבר דחוף.
• הדברים החשובים והלא דחופים (רביע II), הם חשובים באותה מידה כמו הדברים הדחופים (רביע I) = הרי שניהם "חשובים". מדוע לתת להם פחות משקל? אפילו:
• הם עשויים להיות חשובים יותר - בשל הטיעון הראשון.
• הם עשויים להיות חשובים יותר - כי גם הרבה אנשים אחרים בארגון מזניחים אותם.
• אין מה לדאוג. בכל מקרה אנו נקדיש גם זמן לדברים הדברים הדחופים (רביע III, I). מטבעם, יש להם נטייה להתפרץ ללוח הזמנים שלנו.
  כלומר: ההתכוונות לדברים לא דחופים-אך חשובים (רביע II), הוא סוג של "אפליה מתקנת". אם נתמקד בהם - סביר שנגיע לאיזון נכון בין כל הדברים החשובים, דחופים או לא.

ניתן לזכור זאת ע"י הטיפוסים הסטראוטיפיים שמתמקדים בכל רביע:

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

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

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

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

כשאנו במנטליות של "מה לא לעשות" - אנו מאפשרים לעצמנו לאזן בין דברים חשובים-ודחופים (רביע I), ודברים חשובים ולא-דחופים (רביע II).

זו לא "חכמה" להחליט ולוותר על דברים לא-חשובים ולא-דחופים ("למצוא ספק זול יותר לנייר הדפסה"). הקושי הוא לוותר על דברים חשובים או דברים חשובים ודחופים.

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

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

עוד כמה המלצות:

• לארגן את המשימות על בסיס שבועי, שזו רזולוציה שנחשבת טובה יותר מרזולוציה יומית. פגישת weekly עם המנהל, למשל - יכולה להיות הזדמנות טובה לכך.
• לחסום זמן ביומן עבור "משהו חשוב" - ולנצל את הזמן הזה לטיפול דברים חשובים, אך לא דחופים (אני נהגתי לעשות כך במשך תקופה, ובאמת בחצי מהזמן הזה הצלחתי להשתמש בפעול).

ההרגל השלישי מתואר בהרחבה בספר של קווי שנקרא First Things First.

הרגל רביעי: חתור לפתרונות Win/Win עם אחרים (AKA החיים הם לא משחק סכום 0)

כאשר יש חוסר הסכמה מסוים, ובסביבה ארגונית יש הרבה כאלו - באיזה פרדיגמת פעולה אתם בוחרים?

אנשים אפקטיביים נוהגים להתנהל בפרדיגמה של מנצח/מנצח (רביע I).

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

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

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

• חוסר הבנה עם אדם שיש לנו רמת אמון גבוהה איתו - תסתדר במהרה.
• אבל: חוסר הבנה עם אדם שיש לנו רמת אמון נמוכה איתו - יכולה לגרור ספקולציות לגבי כוונות שליליות, אמוציות רעות, והתעסקות מיותרת בדקויות במחשבה שיש מאחוריהן משהו "רע".
• כשאין אמון בין אנשים, הם משקיעים זמן ומאמצים להתגונן בפני פגיעה ("תן לי את זה בכתב", "תוכיח", הוספת באפרים / בטחונות וכו') - זו חוסר יעילות מובנה להתנהלות.
• כשיש אמון בין אנשים, הטעיות נסלחות ביתר קלות, התקשורת היא זורמת יותר, ופחות דברים "נופלים בין הכיסאות". זה כמו דיווידנד ליעילות של הארגון, וקבוצת האנשים בעלי האמון הגבוה - בפרט.
• בניגוד למה שרוב האנשים חושבים, אמון הוא לא דבר מופשט וחמקמק, אלא דבר קונקרטי, מעשי ושניתן לשפר אותו. אינטראקציה טובה עם האדם מעלה את רמת האמון שלנו איתו, אינטראקציה שלילית - מורידה.
  ההשוואה היא "קרדיט" בבנק (בספר: "בנק רגשות"), שבעקבותיו משתנה כל ההתנהגות כלפנו, אך גם ניתן לשפר אותו.

אמון ניתן לשפר בעזרת:

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

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

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

קווי מתאר מודל של התפתחות אישית לאפקטיביות, ובו 3 שלבים:

• תלות - הרמה הנמוכה ביותר, בה אנו תלויים באחרים.
• חוסר-תלות - מצב גבוה יותר, בו אנו לא תלויים באחרים.
• תלות-הדדית - המצב הגבוה ביותר, בו אנו משתפים פעולה עם אחרים ויוצרים תלות הדדית.

ההרגל הרביעי (חשוב "מנצח/מנצח") הוא זה שמכניס אותנו לעולם התלות-ההדדית.

קווי כתב ספר ביחיד עם בנו שמוקדש לנושא. הספר נקרא The speed of trust.

הרגל חמישי: קודם הבן, ורק אח"כ - היה מובן (AKA שתי אוזניים, ופה אחד)

כשמישהו מדבר איתנו, אנו נמצאים באחת מ-4 רמות הקשבה:

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

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

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

אלמנט חשוב בהקשבה אמפתית הוא ניסוח מחדש של דברי האחר, על מנת ש:

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

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


מדוע אלוהים ברא אותנו עם שתי אוזניים, אך פה יחיד? - בכדי שנקשיב יותר ממה שאנחנו מדברים.


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

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


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

הרגל שישי: יצירת סינרגיה (AKA מציאת אלטרנטיבה שלישית)

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

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

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

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

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

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

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

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

כרגיל, ההרגל השישי מתואר בהרחבה בספר משלו של קווי - האלטרנטיבה השלישית.

הרגל שביעי: חדד את המסור (AKA למידה מתמשכת)

ההרגל הזה הוא יחסית טריוואלי: תמיד תמשיך להתפתח.

הלימודים לא מסתיימים באוניברסיטה, לא בחודשיים הראשונים בעבודה, ולא בסמינר שארגן ראש הצוות או ההיא מה HR.

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

"טוב לחטוב את היער הנכון - אבל טוב יותר לעשות את זה עם מסור חד!"

כמה השגות נוספות:

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

אז כיצד הופכים התנהגות - להרגל

הרגל נבנה מתהליך בן כמה שלבים:

• טריגר (נקרא גם Cue) - סיטואציה שמפעילה את ההתנהגות.
• רוטינה - יכולה להיות פיסית, מנטלית או רגשית.
• פרס - שמספק את הלמידה והרצון לעבור שוב את התהליך.

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

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

לדוגמה ארוחה במסעדת מקדונלדס לילדים:

• הסמל של המסעדה בולט למרחקים - זהו טריגר לילדים לדרוש מקדונלדס מההורים.
• ישנה את הארוחה (רוטינה).
• בסופה מקבלים הפתעה (פרס) - שמחזק את החוויה החיובית מהילדים.

דוגמה נוספת:

• התפקיד העקרי של משחת השיניים הוא להיות "פרס" (תחושת הרעננות בפה) שעוזר לנו לשמר את ההרגל החיובי של צחצוח השיניים. הצחצוח הוא מה שתורם לבריאות השיניים.
• למשל: קרם שיזוף לא מייצר תחושה נעימה מספיק, מה שגורם לו להיות הרבה פחות אפקטיבי כ"פרס" להרגל של שימוש בקרם הגנה (שזה הרגל בריא).

דוגמה קונקרטית לתחום שלנו:

• יש ויכוח טכנולוגי שמתלהט.
• אתם בוחרים בגישה של מציאת אלטרנטיבה שלישית.
• אתם זוכים לשבחים על הדרך שבה התנהלתם בישיבה.

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

כדאי שהטריגר יהיה פשוט וברור.

הפרס יכול להיות חיצוני ("שבחים מאחרים") או פנימי (אתם שבעי-רצון מהתוצאה).

סיכום

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

אבל משום מה, הדרך האפקטיבית להתקדם מקצועית היא לא רק להרחיב את מספר הטכנולוגיות שאנו יודעים. האם באמת יש יתרון משמעותי למתכנת שיודע 7-9 שפות תכנות, על זה שיודע 2-3 שפות תכנות?
האם באמת יש יתרון משמעותי למי שמכיר "עוד framework"?

ברמת "הוויכוחים במטבח", להכיר עוד טכנולוגיות זה תמיד טוב - במיוחד כשהן מאוד חדשות ולא מוכרות.
ברמת התוצאות, דווקא כיווני התפתחות אחרים יכולים להיות הרבה יותר משמעותיים ואפקטיביים בפיתוח האישי. היכולת לכתוב בדיקות יעילות, להבין פיתוח מוצר, מתודולוגיות Agile/Lean לעומק, או להבין את הביזנס - יתרמו לנו הרבה יותר מ"עוד טכנולוגיה".

להכיר ולהפנים את 7 ההרגלים של אנשים אפקטיביים במיוחד, היא דרך מצוינת להתפתחות אישית לא-לינארית. במיוחד אם אנחנו מצליחים להפוך את ההתנהגויות הללו בהדרגה להרגלים.


שיהיה בהצלחה!