most of the Iceberg is underwaterרוב הקרחון נמצא מתחת למים

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

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

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

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

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

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

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

-----------------------------------------------------

Our work methodology is probably best described as "Scrum-but": We work side by side, but have distinct separation between testers and developers, We are targeting user stories by priority, but most of the time the developers will continue to the next user story when there are still testing tasks, and we work in two weeks sprints, but release something to production only once in a couple of months. 

This latter "but" has one nice side effect - there are many tasks that need to be done during installation day. Sadly, some of them cannot be done automatically. It may be a new configuration parameter defining an environment property or a password, it can be creating a signing certificate, or contacting a 3rd party to provide us with its public key or just something that should be done only once and was not worth automating. In order to make sure that we do not miss anything on installation day, we create a step-by-step installation guide and then invest a week in testing it. In the last two or three times I took this task on myself, and each and every time I came across something we forgot, or even need some last minute fix. The main advantage I gain in performing the upgrade tests is that it makes it easier for me to wear my OPS hat, and thus notice stuff we missed the first time we tested it - be it procedural limitations (e.g.: in order to keep all machines in sync, OPS keep all files in a source-control server, so we cannot set a requirement to keep the same file with different content. at least, not without providing them enough time to come up with a solution). In this case, I noticed that even without actually doing any work, one of our logs swelled up and took a lot of disk space. Just to be certain - I asked around what is a reasonable log size, and could 1GB per day be acceptable for a while. They said they prefer their logs around 20 MB, so we out got our axe and went woodcutting. 

What was done was simply to move some repeating lines to debug log level, which is normally turned off in production, thus shrinking the logs.
In theory, all should work fine. the change is not risky, and should solve our problem easily. Only it did something else - it turned my focus to the log files, and to the number of times I saw the same line being printed. Cleaning up the extra lines, it was easier for me to see that we are still printing a lot of data over an almost idle process. When I checked this up with the relevant developer he first responded (as he does almost always) "Impossible". I let him vent out a bit of steam (it took me a while to learn this, but in his case, the best way I can make him accept a problem is show it to him, and move aside while he stares at it) and then we understood that the problem was a bit more complex than we first assumed. The lines we were seeing were printed during the process initialization, where some data that should be loaded only once and then cached was being loaded repeatedly. Or, as the experts phrase that: "oops".
After a short investigation we fixed the problem, but I learned two things that I will have to remind myself from time to time.
The first is that in addition to the functional requirements I normally care for, there are always some operational requirements that I keep finding by chance (either when we get lucky and spot this requirement before the code goes live, or when it goes live and we get complaints and a request for fixing stuff).
The second, which should be reiterated every now and then since it is so easy to ignore, is that I see mainly symptoms. Even though I got really good in guessing root cause and impact of various bugs, all that I have are what I see on the surface and a (good?) guess. Usually, when a bug is odd, or dodgy (and sometimes even when it's simple and straightforward), what I see is just the tip of the iceberg, and further digging in is required to uncover the full impact of the actual bug.
I'm not sure yet how to do that, but this is something I want to remain aware of and look for also in the future.