2009-06-22 3 views
0

В PCI/DSS есть требование, указывающее, что журнал приложений должен ежедневно проверяться ежедневно на события безопасности. Большинство профессионалов в области сети/инфраструктуры могут просматривать журналы сетевых устройств, но не будут знакомы с фактическими приложениями. То же самое можно сказать и для большинства специалистов по безопасности.Сколько времени разработчик тратит на просмотр журналов?

Итак, разработчики действительно подходят к этому требованию? Если вам нужно было написать описание работы для разработчика, единственной задачей которого было просмотр журналов, что бы он содержал?

ответ

2

Безопасность/серьезные события, вероятно, должны регистрироваться отдельно, чтобы они были замечены быстрее. Возможно, отправьте их по электронной почте или используйте другую технику, чтобы соответствующие люди были автоматически уведомлены. Никто не должен проверять журналы приложений для поиска событий безопасности. В качестве разработчика я периодически просматриваю производственные ошибки. Я работаю, чтобы получить поддержку, чтобы иметь доступ к ошибкам, и я научу их интерпретировать наиболее распространенные ошибки, но я все равно буду обрабатывать менее распространенные ошибки. Также, когда я просматриваю ошибки prod, я оцениваю сообщения наиболее распространенных ошибок для их улучшения.

Поэтому я думаю, что разработка должна периодически просматривать ошибки prod, следить за тем, чтобы важные (т. Е. Журналы безопасности) автоматически отправлялись соответствующим людям и обрабатывали обработку наиболее распространенных ошибок для других групп (инфраструктура поддержки, безопасность и т. Д.), , Если бы кто-то исключил ответственность за просмотр журналов, я бы не назвал их разработчиком.

1

Я лично не вижу, чтобы разработчики подошли к этому требованию. Большинство разработчиков занимаются разработкой ... не с тем, с кем бы справился эксперт по приложению.

Если бы я написал описание вакансии для разработчика, чья единственная работа рассматривала журналы, она содержала бы кое-что об изучении архитектуры приложения и становилась экспертом в использовании и внедрении программного обеспечения.

0

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

Подумайте об этом как о бета-фазе пост-релиза.

До тех пор, пока мы находимся в этом , приложение - это жизнь; но еще не выпущен QA фазе, я просматриваю журналы не реже одного раза в день. (Конечно, у нас есть другие способы получить уведомление об ошибках, но я много узнал о своих собственных плохих предположениях о том, как пользователи будут таким образом управлять программным обеспечением).

0

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

2

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

Для других проблем, я ожидаю, что вас уведомят.

  • Если система имеет значительные проблемы, я бы ожидать, кто по вызову, чтобы получить выгружаемого
  • Если есть исключения броска, я бы ожидать, те, которые будут зарегистрированы, и их резюме, чтобы быть легко доступны либо на веб-странице, либо на адрес электронной почты

Для меня «разработчик, чья единственная работа должна была проверять журналы» - это оксюморон: если вы просто просматриваете журналы, вы не разрабатываете, поэтому вы не разработчик.

Смежные вопросы