|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Slava Astashonok 2:5020/400 21 Jun 2005 22:07:26
To : Aleksey Barabanov
Subject : Re: coda fs
--------------------------------------------------------------------------------
Aleksey Barabanov wrote:
> Конечно, конечно. Просто у меня "good practice" иной/иная. И поэтому я готов
> признать ее не "good", если вы укажите на несоответсвие стандартам.
Hе укажу. Мне не пришлось углубляться до технической стороны вопроса -
остановился на административной. Hо скорее всего этих несоотвествий нет.
> Как я это вижу.
>
> 1.Шареный ящик.
>
> Проблема в том, что криворукие "усера" лезут в чужую почту и дропают ее. А
> на админа стрелки переводят.
Hе важно переводят ли юзера стрелки, главное что могут дропнуть. Ещё один
аспект: предположим юзер увольняется - что дальше? Менять пароль и оповещать
всех пользователей шары? А если ресурс локальный и доступ извне к нему закрыт
представим, что юзер не уволился, а перешёл в другой отдел. Для крупных
контор, в которых чуть ли не каждый день что-то происходит - один увольняется,
другой нанимается это будет реально головная боль сисадминам. При потере или
утечке информации очертить круг ответсвенных может стать затруднительно и в
результате крайним будет именно сисадмин.
> 2.Раздублированная по приватным ящикам почта.
[...]
> 3.OTRS
[...]
> Какой же выход ?
Hужно сперва разобраться с назначением адреса, что это - список рассылки или
reception/support/т.п. Если первое, то оптимальным решением для малого
количества читателей будет банальный aliases; для большого - mailman или
аналог. И, что немаловажно, процесс перехода от одного к другому будет
прозрачен для пользователей.
Если же адрес - это reception/support, то в первом приближении расшарить ящик
кажется простым и эффективным, но кое-какие соображения я уже высказал выше. К
сказанному добавлю, что это решение плохо масштабирутся - с ростом количества
работников повылазят грабли. Отсутсвует и требует изобретения нового
велосипеда вся процедура обработки заявки/тикета, например, наиболее
необходимые действия - блокировка (обеспечиние атомарности, чтобы над одной
задачей не начали работать сразу несколько) и просмотр текущего состояния
заявки/тикета. Это всё начнёт ощущаться очень скоро - буквально с третьего
супортщика. В итоге сэкономленное в начале время будет сторицей растрачено в
процессе эксплуатации.
Вот такое моё мнение.
--
"A witty saying proves nothing." -- Voltaire
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
| Тема: |
Автор: |
Дата: |
|
Re: coda fs |
Slava Astashonok |
19 Jun 2005 23:12:32 |
 Re: coda fs |
Aleksey Barabanov |
20 Jun 2005 11:26:57 |
  Re: coda fs |
Slava Astashonok |
20 Jun 2005 19:44:21 |
 Re: coda fs |
Aleksey Barabanov |
21 Jun 2005 11:12:11 |
|
Re: coda fs |
Slava Astashonok |
21 Jun 2005 12:27:12 |
|
Re: coda fs |
Aleksey Barabanov |
21 Jun 2005 13:57:08 |
|
Re: coda fs |
Slava Astashonok |
21 Jun 2005 14:47:04 |
|
Re: coda fs |
Aleksey Barabanov |
21 Jun 2005 17:42:33 |
|
Re: coda fs |
Slava Astashonok |
21 Jun 2005 22:07:26 |
|
Re: coda fs |
Sergey Prokopenko |
22 Jun 2005 15:22:51 |
|
Re: coda fs |
Artem Chuprina |
27 Jun 2005 18:42:41 |
|
|
