היישום פועל לאט? זמן לדייק

על ידי צוות Techopedia, 31 באוגוסט 2016

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

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

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

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

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

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

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

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

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

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

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

דז בלנשפילד: היי, תודה לאריק. תודה. הוביל יפה אל הסגרה הקטנה שלי. הכותרת שלי, "אמנות פרפורמנס", אני חושבת שמתאימה מאוד בהקשר של מה שאנחנו מפטפטים עליו היום, מכיוון שבמובנים רבים כשאנחנו חושבים על אמנות מיצג, אנחנו חושבים על ריקודים ומוזיקה ועוד דברים יצירתיים. ולמען האמת לעתים קרובות יותר מאשר לא, אם אנו פותרים בעיות ובסביבות IT ובמערכות עסקיות בהיקף גדול מאוד, אכן יש אלמנט של אמנות ולעיתים קרובות אמנות שחורה, מכיוון שהסיטואציה שלי מניסיוני בכ -25 פלוס שנים היא שה ערימות אפליקציות מודרניות מגבירות במהירות את המורכבות בקצב שמעולם לא ראינו. ואנחנו נאבקים בכנות להמשיך בקצב ויש ארגונים כמו Uber למשל, ומה שלא יהיה, וצוות הפיתוח של Pokémon Go, אני מתכוון שהם חווים צמיחה ומורכבות וגידול מורכבות בשיעורים שהם פשוט אסטרונומיים. אין אפילו ספרים שנכתבו על זה כי לא הגהנו את רמת הצמיחה הזו. דעתי היא שההגדרה העיקרית של מחסנית אפליקציות השתנתה באופן אקספוננציאלי ואני הולכת להסביר מדוע אני חושבת שזה המצב ואז להוביל לאתגר העומד בפני, כי נראה כי חברי הטובים באי.די.איי יש פיתרון לפתור .

בקצרה מאוד, כולנו מכירים את אלה אבל רק כדי לסכם אותם, אתה יודע, בימים הראשונים היה לנו מה שאני מכנה, ארכיטקטורת יישומים, גרסה 1.0. זה היה מחשב שרת, במקרה זה המיינפריים עם חבורה של מסופים מחוברים, היה קל יחסית לאבחן בעיות אם לא היית רואה דברים בטרמינל - אתה יכול לאתר את הכבל בין הטרמינל ואז למחשב השרת., וזה היה כבל אפס או מחבר או בעיה כלשהי אם זה לא היה קשור למסוף ואתם רואים דברים על המסך, היה די קל להבין שהדברים שגורמים לבעיות היו בתוך המכונה עצמה. ואתה יכול לאבחן לאט איפה בערימה שהיה מהחומרה עד לשכבת התוכנה ולממשק המשתמש. במה שאני קורא לו גרסה 1.1, הפכנו את זה למעט יותר מורכב. שמנו מכשירים באמצע כדי שנוכל להציב מסופים נוספים במקום. והם היו איזשהו מכשיר תקשורת ולעיתים קרובות הם היו muxes או multiplexers והם היו עוברים על קו ייעודי או קו חיוג וכך היה לך מיינפריים במיקום מרוחק - זה יכול להיות בין עירוני או בינלאומי - ואיזה מכשיר מחובר דרך קישור SMA או קישוריות WAN כלשהי והמסופים האלה עדיין פועלים באותה צורה. אבל היה לך קצת יותר מורכבות כי היית צריך להבין אם הבעיה היא בין הטרמינלים למכשיר ה- comms או התקן ה- comms וה- mainframe. אבל הערימה נותרה דומה יחסית במיינפריים.

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

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

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

כשאתה מגיע לתוכנה כשירות, ומודל מסורתי של זה הוא דואר אלקטרוני או בנקאות באינטרנט, כל מה שיש לך זה גישה לדפדפן אינטרנט, אז לנסות לאבחן מה עומד מאחורי זה בלתי נסבל, בהחלט. ופרקתי את זה לאזורי זמן, למקצבים של זמן או אזורי זמן אם תרצו או דורות, משמאל לימין, עברנו מעין שנות ה -2000 והערימה המסורתית בה הייתה לנו גישה לכל הסביבה ויכולנו להתעמק בזה. אך עם הזמן זה נעשה מורכב יותר ויותר. לתחילת שנות האלפיים עד אמצע 2000, עד סוף 2000 עד היום, בו עברנו משירות תשתית, שירות פלטפורמה, שירות תוכנה, עד עכשיו אנו מתייחסים למעשה לשירות עסקי. והמורכבות גדלה באופן דרמטי. יש כל כך הרבה חלקים נעים יותר. אולם זמינות המיומנויות נעשית קשה יותר ויותר ויותר ויותר קשה להשתמש בה. מציאת אנשים בעלי מיומנות נכונה עם גישה נכונה לכלים הנכונים להכנס לצלול לתוך המחסנית הזו ולברר איפה משהו פועל לאט. האם זה המחשב הנייד שלי או שולחן העבודה שלי, האם זה הטלפון שלי או הטאבלט שלי, האם הקישוריות שלי מעל 3 או 4G, או הקישור הייעודי שלי עם ADSL, או ISDN מה שיהיה? או אפילו בחיוג, למרות שזה פחות ופחות המקרה בימינו. האם סוף שרת האינטרנט, האם זה משהו בתוך שרת האינטרנט? האם זה שרת האפליקציות? האם זה משהו סביב הזיכרון והדיסק של ביצועי המעבד והרשת בתוך שרת היישומים? האם בסיס הנתונים פועל שם?

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

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

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

ואז עם זה אני אעבור לחברנו היקר מ- IDERA, ביל אליס, ולראות מה יש לו היום לומר על איך הם פותרים את הסוגיה הזו. ביל, לך.

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

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

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

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

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

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

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

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

זיהוי משתמש הקצה חיוני. בסופו של דבר זה חיוני ש- IT יוכל לעזור למשתמש קצה מסוים. כעת, מה שעשינו כאן, עברנו לכרטיסייה "זרימה". אתה יכול לראות את זה בפינה השמאלית העליונה. והתמקדנו במרכיב מסוים בתפריט האינטרנט. ובצד ימין ניתוח של אותה עסקה מסוימת, וכך בחלקו העליון זה בעצם הדפדפן ואז ה- View, רק כדי להכיר קצת את הסמלים בתוך ה- GUI מיועד לשרת האינטרנט, אז אנו יכולים לראות את נקודת התכונה. ואז ה- "J" מיועד ל- Java וה- "T" הוא עבור טוקסידו ובאופן טבעי ה- "Q" הוא SQL. ובכן, ערך המזומנים מזהה למעשה הצהרת SQL מסוימת. שקול מה זה עושה. זיהינו משתמש לעסקה, לקוד היישום הבסיסי, כולל הצהרות SQL בודדות. כעת, כשאני מסתכל על אותן הצהרות SQL נפרדות, אני יכול לראות שזמן התגובה הכולל, כל אחת מהן אחראית לכשישה אחוזים, וכשהן מוסיפות את ארבע הצהרות ה- SQL המובילות, הן לקחו כרבע מהעסקה זמן.

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

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

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

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

כעת, אלה חלק מהציטוטים ואלו קורים מחנות PeopleSoft עם פריסה עולמית. Precise תומך ב- PeopleSoft ו- SAP, Siebel, Oracle, E-Business Suite, יישומי Java ו Java .NET ביתיים. אנו תומכים בכך שאם אתה מבצע שיחות של שירותי אינטרנט למספר JVMs, מג'אווה ל- NET בחזרה לג'אווה, נוכל לעקוב אחר כל זה. זה יכול להיות מראש, זה יכול להיות בענן. הדבר המכריע הוא שדברים צריכים להיות מכשירים.

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

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

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

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

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

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

רציתי לשתף אתכם בכמה סיפורים, סוג של "הצלחה במרכז הנתונים". ואלה ממוקדים בבסיסי נתונים ויש לי סיפורים אחרים שממוקדים בינונית. אבל להיום אני באמת רוצה להתמקד ברובד הנתונים. בואו נסתכל על הקפאת המסך. מה שקרה כאן הוא שלחנות הספציפית הזו היה SLA עסקי, שאם תתקבל הזמנה בשעה 15:00, ההזמנה נשלחת באותו יום. וכך המחסן עמוס מאוד במהלך אותו זמן. ואז עם הקפאת מסך זה היה מאוד מתסכל. וכך המפקח - זו חברה קטנה יותר - המפקח למעשה נכנס ל- IT וכמובן ניגש ל- DBA ואומר "עכשיו, מה קורה?" וכך מה שעשינו, האם הצלחנו להראות בדיוק מה קורה. עכשיו זהו JD Edwards, אפליקציה רב שכבתית, זהו מסך הזמנת המכירה. אתה יכול לקבל מושג מה היה העסק, בעצם מלאי בדיוק בזמן, וכך אתה בעצם בודק יישומי מחסן. ועכשיו אתה בעצם משלוח למספר אתרי לקוחות שונים, חנויות שונות. ומה שעשינו זה שפתחנו את Precise.

עכשיו במקרה זה, לפני שבחנו את אורקל, כאן אנו מסתכלים על SQL Server, ועכשיו המחצית העליונה מציגה לנו תרשים עמודות מוערך של היכן הצהרות ה- SQL מבלות את זמנן במהלך הביצוע. כל מצב חלש אחראי בציר ה- Y. ציר ה- x אם כמובן לאורך זמן ותוכלו לראות שגרף העמודות הערום משתנה מפרוסת הזמן, תלוי מה ביצועו וכיצד הוא משתמש במערכת. עכשיו במקרה הספציפי הזה התמקדנו ברצף ה- SQL השלישי מלמעלה. זה כתוב עם טקסט SELECT מ- PS_PROD ותוכלו לראות בעמודה ההיא שכבשנו את תוכנית הביצוע בפועל. ותוכלו לראות לאורך מספר ההוצאות להורג. העובדה שהצהרת ה- SQL הספציפית הזו הייתה אחראית על 9.77 אחוז מצריכת המשאבים במהלך פרק הזמן הזה בו אנו מסתכלים - וזו נקודה חשובה, מסגרת הזמן, Precise שומרת על היסטוריה מתקדמת - וכך אני בעצם יכול לחייג ולברר מה קרה בכל נקודה מסוימת בזמן או לאורך זמן. אני מסוגל לראות מגמות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דז בלנשפילד: בהחלט. שאלה אחת מהירה אחרת בדיוק במבחן המפרט הזה - מבחן עומק, הגירה, UAT וכדומה - זאת אומרת, זה נהדר לקבל את הכלי הזה ואני מתאר לעצמי שמפתחי אפליקציות בהחלט יאהבו לקבל גישה לכך דרך מחזורי החיים של מחזור חיי הפיתוח. . עם הארכיטקטורות המורכבות יותר שאתם רואים עכשיו, כך שעברנו משירות ייעודי לווירטואליזציות ווירטואליזציה, אנו עוברים כעת לאמצעי, אתם יודעים, אימוץ מיקור חוץ למארחים בענן ואנחנו רואים גם מעבר למכולות. האם ראית אנשים רבים פורסים את זה ומדגמים סוג של אזורים או אזורים, אז למישהו יכול להיות - ובאוסטרליה יש לנו נושא מאוד גדול סביב פרטיות ואני יודע באירופה שזה אותו דבר ואני חושב שזה הופך להיות מקרה יותר מעניין בארצות הברית, שם נתונים שמסוגלים לזהות אותי באופן אישי נדרשים לעתים קרובות להיות בסביבה בטוחה יותר לשכבת היישום בפועל לשכבת האינטרנט. וכך יש לנו פריסות אלה כעת בהן אנשים עשויים לשמור על מסד הנתונים שלהם ואת דברים היישומים שלהם באופן פנימי, אך הם יכולים לשים את שכבת האינטרנט שלהם ואת סיום המסירה שלהם ואת היישום שלהם וכן הלאה בספק ענן כמו Azure או, או Amazon Web Services and software . איך זה עובד עם הפריסה הרגילה שלך? האם זה מקרה שיש לך בדיוק קבוצה נוספת של אספנים באזור והם פשוט צוברים עוד כמה? איך זה נראה בעולם המדויק בסגנון של היום הבימודלי של הפעלת ה- IT של דברים ישנים במקום אחד והסחורה שלך לפעמים בענן?

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

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

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

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

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

דז בלנשפילד: אריק, בפניך, יש לך שאלות אחרונות?

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

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

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