Комментарии 29
А меня есть тоже пара уроков, вынесенных из аварий в космосе и в самолетостроении. Данные уроки больше для разработчиков электроники, а не только софта:
Всегда имей "Черный ящик" — т.е. еще до того, как система или устройство разработано и запущено, предусмотри систему сбора данных на случай сбоев или отказов для возможности пост-анализа. Пусть это будет простой лог файл или буффер — но обязательно предусмотри. Не рассчитывай, что тебе кто-то расскажет, как все было. Когда твое устройство накроется, а ты не будешь знать почему — это поможет.
Это тоже из космоса: Никогда не пытайся решить проблему (или фиксить баг) на обум, т.е. пока ты не докопаешься до причины. Потрать 1-2-3 дня на выяснение, даже если ты уверен, что решение займет минуты.
Слишком часто я видел уверенных программистов, которые смотрят на проблему и говорят мне:
— А, я догадываюсь в чем проблема, счас пофиксю за 5 минут.
Прихожу на следующий день:
— Пофиксил?
— Нет, не сработало, счас работаю над вторым вариантом
— Сколько времени надо?
— Да, не больше 5 минут.
На следующий день:
— Пофиксил?
— Нет. Этот вариант тоже не сработал, но у меня есть…
— Стоп! Теперь предлагаю я. Что ты сделал, чтобы лучше диагностировать дефект? Ты пробовал его воспроизвести в этой ситуации?
— Нет.
— А в этой?
— Нет, это займет 5 часов на написание теста, а у нас нет времени…
— Да, но я знаю, что через 5 часов мы будем знать больше о дефекте, чем до этого. Поэтому делай. И я даю тебе еще целый день на то, чтобы ты добавил отладочные порты, а не жду от тебя фикс..
В итоге ошибка была в совершенно другом месте, чем думал программист...
На каждом митинге, где я упоминал про необходимость логов, на меня смотрели как на фрика и крутили пальцем у виска, «да какие логи! на это нету времени! просто не будь рукожопом!» и другие сказки о мифических единорогах-ниженерах, которые делают всё с первого раза и никогда не ошибаются.
ни НАСА не знали об испытании
Это вы, простите, гоните. Майкл Фолл был командиром экипажа. Не знать, что происходит на станции он не мог.
История с Волыновым напоминает ещё историю с катастрофой Ту-104, командир которого во время падения передавал в эфир показания приборов — самому́ ему это не помогло, но переданные сведения помогли потом исправить другие экземпляры той же модели.
И всегда имей реплику удаленной системы под рукой, на которой тестируешь все изменения таким же образом, как это сделал бы на удаленной.
Только не забывай её выключать, когда работаешь с удалённой. А то при попытке связи с "Луной-3" ответы имитатора из соседнего здания приняли. Хорошо, время было, и успели его выключить.
не зря одно из правил админа: через терминал удаленного доступа все сервера кажутся одинаковыми
Как-то раз по-ошибке набрал halt не на локальной машине, а в консоли, подключенной по ssh к удалённому контроллеру.
Пришлось ехать на другой конец города, включать.
В баше можно цвет командной строки запроса менять.
У меня в проде, в деве, и под рутом обязательно цвета отличаются. Настраивать надо всего раз в отличии от клиентской части.
Если сервер под виндовс, то обязательно обои определённого цвета с текстом ввиде имени хоста, как минимум.
Ну и в идеале цвет окошек в темах под определённый стандарт подогнать.
удаленно настраивать фаервол - к дальней дороге.
Измученный разработчик библиотеки, работавший ночью, пропустил всего один пробел
Чего стоило этого бедному разработчику!
Книга Чертока Ракеты и люди очень информативна в этом плане. Как они ракеты испытывали. А еще мемуары Грабина. Про испытания пушек
Чему меня, как разработчика, научили аварии в космосе