Какво е situation awareness?

Терминът се среща основно при обучението на пилоти и описанията на самолетни катастрофи. Не открих хубав превод, затова ще се опитам да го обясня – това е осъзнаването и познаването на средата, в която се намирате.

Освен самолетни катастрофи, липсата на situational awareness е причина за много причинени проблеми, изгубени данни, неработещи услуги, както и, по-прозаично, за много загубено време на програмисти и системни администратори. Дори има една проста поговорка, която го илюстрира – „две седмици усилена работа спестяват 10 минути четене на документация“. Също така имаше един друг прекрасен пример в един клип от Soft Uni с return, return, който вероятно всички познавате.

Описание на проблема

Никой от нас не работи във вакуум. Дори писането на сравнително прост код включва след себе си цяла редица от неща, като тръгнем от текстовия ни редактор, през средата в която работи, до средата, в която кодът ни се изпълнява – или от админска гледна точка, от командата, която пускаме, до многото странични желани и нежелани ефекти, които има поради особеностите на средата, в която работи.

Един пример за команда, известен като „да си отрежеш клона, на който седиш“, е да си преконфигурираш и съответно спреш мрежовия интерфейс, през който достъпваш някакво отдалечено устройство. На много хора им се е случвало да натиснат Enter, да видят, че изведнъж терминалът им е замръзнал и да осъзнаят какво се е случило. Усещането не е приятно, а мислите които ви сполитат, докато отивате на място (или звъните на някого да отиде пак на място да го оправи) – още повече.

Някаква част от това се дължи на непознаване на средата, друга – донякъде на липса на средства за наблюдение, но основно на липсата на подходящи навици и на идеята, че са ни нужни. Както шофирането изисква постоянно наблюдение и усещане за средата, така всяка една работа с каквато и да е система изисква същото, и еквивалента на звуци от двигателя, табло и т.н..

Инструментариум

Инструментариумът ни за тези неща се дели на няколко части – хардуер, „среда“ и „продукт“.

Хардуерната част е сравнително ясна. В зависимост от това как работите ви е нужен достатъчно голям монитор, два или три, така че докато работите върху нещо, да може да следите какво се случва с него, т.е. да имате пред себе си не само това, с което работите (напр. терминал), но и информация за него в отделен прозорец на същия монитор или още по-добре на съседен, видим такъв.

Има много информация как да си направим работната среда ергономична и удобна, и ще оставя на вас да харесате подходящия за вас самите начин. Мога да споделя за моята работна среда, че основно работя на един, квадратен монитор (Eizo FlexScan EV2730Q), който ми позволява да виждам едновременно няколко различни терминала и поне един log, т.е. има достатъчно и широчина, и височина, за да събира нужния ми текст. Също така съм отделил на друг монитор (и друг компютър като цяло) всичките си аудио/видео разговори, така че да не ми се смесват с работата и да мога да гледам едновременно хората, с които работя и работата си, без това да пречи на работната ми среда.

В частта „среда“ имам предвид работната ви desktop среда, която зависи от операционната система и навиците ви. Това е тема, която заслужава отделна статия; единственото, върху което бих наблегнал тук, е нещата трябва да са лесни за виждане и четене и нещата, които трябва, да могат лесно да ви привличат вниманието. Правилните шрифтове, цветови схеми, методи на известяване са неща, на които определено си струва да обърнете сериозно внимание.

И в частта „продукт“ става въпрос за самата система, с/по която работите. Почти всяка система, която ползваме, притежава някакъв интерфейс за debug-ване, било то (подробни) логове, конзола, или в краен случай възможност да се ползва външен debugger за наблюдение. Би трябвало да е сравнително лесно да се намерят и да ги ползвате, докато работите, за да имате бърза обратна връзка за ефекта на действията, които извършвате. Също така е важно да имате под ръка удобен инструмент, с който може да оправите проблем, ако се появи – било то отворен административен интерфейс, друг терминал, или дори подготвена команда, която разкача от системата това, по което работите, и прехвърля работата му на друго място.

Нещо допълнително, което съм намерил за доста полезно, е да имате също удобен начин да разглеждате source кода на нещата, с които работите. Доста често контекстът и смисълът на дадена грешка стават по-ясни от мястото ѝ в кода и какво се случва около нея, вместо в документацията или самото ѝ съобщение.

Познаване и очаквания

Разбира се, само инструментариумът не решава проблема – трябва да можете да реагирате по някакъв начин на случващото се, и да знаете какво се очаква да се случи, какво не се очаква, и ако има нещо, което е неясно, как да разберете какво е.

Това изисква познаване на системата и поведението ѝ. Такова се изгражда чрез няколко неща, които не са взаимно изключващи се:
– познаване на теорията, протоколите и зависимостите на системата;
– запознаване с документацията и обещанията (обещания, защото не винаги може да им се вярва) за начина на работа, който може да се очаква;
– изследване на реалното поведение в различни ситуации, най-често експериментално.

В началото, докато се запознаваме/откриваме нещо ново, опитът ни да разберем дадени съобщения и поведения може да доведе до много въпроси, които да се сторят глупави на колегите ви, но поне моят професионален опит показва, че задаването на глупави въпроси е по-безболезнено и за двете страни, за разлика от оправянето на проблемите, които бихте могли да предизвикате. (Друг полезен ефект на глупавите въпроси е това, че показват пропуски или неточности/неясноти в документацията).

 
Разсейване

Възнамерявах да спомена това в секцията за средата, но реших, че този проблем  заслужава отделна точка. Без значение какво правим, е важно да имаме минимално количество разсейващи фактори и да виждаме само това, което ни е важно или нужно в момента, без излишни неща, които изискват внимание или замисляне.

Това основно включва ограничаване на notification-ите само до пряко нужните за работата, понякога обясняване на хората около вас „сега правя нещо опасно“, „сега имам да измисля нещо“ и т.н., а в някои крайни случаи – спиране на всичко, оставяне на един текстов редактор и писане (почти както правя в момента, докато пиша тази статия 🙂 ).

Друг момент, който често се пренебрегва, е това, че трябва да сте наясно със собственото си състояние, докато правите нещо. Най-страшният код, който съм писал, е бил докато съм бил с температура (което на мен ми се отразява като ме заблуждава да мисля, че съм добре а всъщност това далеч не е така) – пълен с глупави скрити някъде грешки, които после отнемат по цял ден да се открият и коригират. В нашия екип когато някой не се чувства достатъчно адекватен и добре (например не е спал по някаква причина), не го занимаваме с пряка оперативна или критична работа и си разпределяме оставащите задачи. Това определено има положителен ефект върху цялостните резултати от задачите ни.

Или по-кратко казано, да се считаш за безсмъртен и безгрешен във всякакви ситуации много бързо се доказва като невярно.

Пример от работата

Ще илюстрирам с писането на парче код, което прави заявка до определен web service. За да знаем какво се случва, би трябвало лесно:

– да виждаме кода, по който работим;
– да можем да го пускаме в режим, който казва какво прави;
– да можем да виждаме log-овете на отсрещното приложение;
– да имаме начин някакъв monitoring да ни извести, ако сме счупили нещо генерално по отсрещната система.

(Последното е особено важно, за да се подсигурим срещу „неизвестните неизвестни„, от типа на „без да искахме, препълнихме диска на една трета log-ваща машина“).

Аз бих го реализирал по следния начин, който се вижда по-горе: в един прозорец имам кода + някакви помощни неща, в друг го пускам и същевременно виждам какво се случва отсреща. Превключвам между двете с една клавишна комбинация, превключвам вътре в под-прозорците с друга, и на съседен workspace имам отворен терминал, с който мога да ровичкам по средата отсреща, ако ми се наложи. На друго място си имам browser, чрез който да разглеждам някакви неща, и системният monitoring ми изпраща notification-и, които ми изскачат най-отгоре на работната среда. (В практическата си работа понякога използвахме телефона на един колега, който издаваше определен звук при notification от monitoring системата и имахме идея кога има нужда да гледаме, дори да пропуснем визуалния notification).

 
Защо?

Тази статия е преработен вариант на наш вътрешен training, породен от операторска грешка. Нещата вътре са основно от нашата практика и работа, не просто добри идеи 🙂

Васил Колев, Системен Администратор/DevOps в StorPool

Васил се занимава със системна администрация и като цяло изграждане и поддържане на системи от около 20 години. Освен стандартните web-базирани неща се е занимавал с развитие и поддържане на инфраструктура в сфери като телефония, high-load/performance services, криптография, security audit-и, видео streaming. Участвал е в провеждане на интервюта и събиране на екипи, организиране на конференции, преподаване във ФМИ и други.

 

 

Share This