Логи и безопасность - практика показывает

Надавно высказывал свои размышления на тему логов и безопасности... Сегодня на хабре попалась заметка о реальном случае, подтверждающем то, что к логам надо относиться более внимательно и осторожно )

Игры со временем продолжаются

Только-только утихли споры по поводу перехода на постоянное летнее время, даже самые ленивые админы уже обновили tz-либы на своих серверах . И вот-те на. Опять , по-видимому, грядет переход - теперь на "постоянное зимнее". Понятно, что кому-то хочется удовлетворить свой законотворческий зуд, кому-то хочется набрать очков в глазах избирателей, которым пришелся не по нраву прошлый перевод, а кому-то хочется опять хоть как-то войти в историю (на худой конец вляпаться). Ну а нам опять, судя по всему, пере-привыкать, пере-проверять и пере-накладывать патчи. А принимая во внимание хоть и туманную но перспективу Медведа вернуться в Кремль через ННое количество лет, старые патчи предлагаю далеко не убирать - вдруг опять на летнее ? :)

mercurial: +100 к гибкости

Недавно обнаружил замечательное расширение для hg : crecord.
Оно позволяет делать построчные коммиты - то есть, выбирать конкретные строки, которые включить в очередной коммит.
Допустим у вас есть измененный файл и в стандартный diff попадают изменения , сделанные в рамках двух разных доработок. Изменения по одной из доработок вы хотите закоммитить,  а изменения по другой - пока не хотите. В этом случае как раз и поможет данное расширение..

Установка и подключение предельно просты:

1. выкачиваем расширение в локальную директорию из репозитория (расширение еще не включено в список стандартных)

$ hg clone https://bitbucket.org/edgimar/crecord

2. редактируем .hgrc файл  

[extensions] 



crecord = /путь/до/каталога/crecord/содержащего/__init__.py/ 

И теперь можем использовать как новую команду для hg:
$ hg crecord

В результате отображается консольный интерфейс с возможностью выбора отдельных файлов и отдельных строк в файлах, причем строки можно выбирать группами.

p.s.

Без багов, конечно же , тоже не обошлось:

hg crecord требует указания имени пользователя.
Требует - указываем ... через стандартный для hg  параметр -u

$ hg crecord -u someuser
.. а он не понимает и продолжает требовать.

Приходится явно прописывать в .hgrc

[ui]
username = someuser
Приятного использования!

Тестировщики и тех.поддержка: взаимовыгодное сотрудничество

Вопросам взаимодействия тестировщиков и технической поддержки уделяется гораздо меньше внимания , чем, например отношениям тестировщиков и разработчиков. Хотя, на мой взгляд, тут также довольно много разных тонкостей, психологических моментов, проблем , стереотипов  и всяческих там особенностей.
Сотрудники технической поддержки находятся на самом "острие" , ежедневно общаясь с заказчиком, мотаются по командировкам , где зачастую в стрессовых ситуациях вынуждены оперативно решать технические проблемы, прикрывая порой промахи остального коллектива, оставшегося в уютном оффисе. Саппортеры - первые, кто узнает о проблемах заказчиков, фильтрует всяческие ошибки настройки от реальных багов. Благодаря близости к "реальной эксплуатации" техподдержка обладает особо ценными знаниями о конфигурациях софта, о типичных действиях реальных пользователей, об реальных объемах баз данных и еще о многом таком, о чем тестировщики могут только догадываться. В общем, "сильные стороны" тех.поддержки очевидны. Переворачивая известный афоризм , можно  сказать , что "недостатки техподдержки являются продолжением их достоинств". Сотрудник тех.поддержки зачастую не знает досконально всех особенностей системы и не настолько глубоко в нее "погружен" как разработчик или тестировщик. Поэтому порой ему недостаточно знаний о системе, чтобы точно поставить "диагноз" той или иной проблеме и, тем более , выявить точную причину произошедшего сбоя.
Тестировщики же, наоборот  , зачастую "оторваны от реальности" , не обладая полным пониманием всех тонкостей и особенностей того, как именно используется софт " в бою".
Исходя из вышесказанного должно быть понятно, почему вопрос взаимодействия тестирования и тех.поддержки - довольно важен. Для менеджмента и руководителей этих подразделений важно не только решать всяческие шероховатости, конфликты , возможные взаимные производственные споры сторон, но и налаживать и отлаживать процесс обмена знаниями. Тестировщики должны быть более осведомлены о "реалиях" использования софта для того, чтобы само тестирование стало более адекватным и направленным на реальные, а не вымышленные или высосанные из пальца  сценарии и конфигурации. Сотрудники тех.поддержки должны быть более информированы об особенностях этого самого софта  , чтобы давать более точные  и оперативные рекомендации заказчикам.
Процесс обмена знаниями можно построить по-разному.
Я бы хотел поделиться собственным положительным опытом организации и участия в одном из вариантов подобного обмена.
А именно в некоей ротации.
Время от времени сотрудникам технической поддержки передаются задачи на регрессионное тестирование тех или иных частей системы. Почему именно регрессионное?  Потому что в этом случае саппортеру не надо выдумывать тесты, погружаться в теорию и практику тест-дизайна - он проверяет работоспособность по методикам тестирования , которые , к слову, после работы с ними техподдержки , становятся намного богаче и адекватнее.
В то же самое время тестировщикам время от времени поручается разбор кейсов от заказчика, в ходе которого ребята по-новому начинают смотреть на вроде бы уже досконально знакомую систему и наборы своих тестов. А также, что немаловажно - переоценивают свою меру ответственности за общий результат.
Вот такое вот взаимовыгодное сотрудничество.