С удивлением прочитал новость, что padfone таки добрался до рынка. Полгода назад взял бы наверняка, как только цена пришла к разумной.
Сейчас же, в свете выхода машинок на WP8, возникает вопрос: планируется ли аналогичный девайс, но уже на основе WP8?
Или пока еще рано говорить о планшетизации именно WP8 из-за позиционирования WinRT как ОС для планшетов?
его только нужно чуть-чуть изменить: при распределении подписки, брать полное время «просмотров». и каждому фильм/ролику отчислять кусочек подписки пропорционально времени просмотра.
т.е. если пользователь посмотрел за месяц 3 фильма по 2 часа и 1 ролик на 5 минут, фильмам уйдет ( 10уе * 120/365 ). ролику — (10уе * 5/365).
причем, в эту схему укладывается и «уход с просмотра» — начал смотреть фильм, не понравилось — выключил. в зачет фильму пошли не 2 часа, а первые несколько минут. с «растянутыми» роликами аналогично — перемотка же не будет временем просмотра.
ps: да, речь про онлайн просмотр. если позволять «оффлайн», нужно или заморачиватьс с оффлайн подсчетом времени просмотра или тупо зачитывать всю длительность.
pps: вообщем-то эту схему явно можно применить и к музыке и тд.
Аналогично, первая страница вызывает реакцию «а оно вообще работает?».
потом на границе видимости обнаруживается полоска-прогрессбар, которая еле ползет.
думаю, гораздо удобнее было бы видеть картинку-фон «Подождите, загружается интерфейс» или что-то подобное. а не просто пустую страницу с серым фоном.
(ну и само собой, какую-нибудь надпись для случаев повышенных настроек безопасности — если убрать домен из зоны «доверенных», открывается просто пустая страница)
Саму регистрацию пройти сложно из-за города.
да и вообще не совсем понятно, зачем вводить персональную информацию сразу, при регистрации.
после регистрации, пришло письмо, открыл ссылку. открылся сайт. т.к. никаких надписей про «вы прошли активацию» и тп не увидел, внимательно смотрел на страницу. обнаружил в самом верху нижнюю часть стрелочки ">". ради интереса нажал — оказалось, это продолжение активации.
после ввода емыла (зачем? код активации же уникален для пользователя?), открылся попап с требованием заполнить кучу персональной информации. прокликал, т.к. не вижу смысла вводить инфу до знакомства с сервсисом. да и сервис не затребовал вводить что-либо. (если бы затребовал, точно закрыл бы уже на этом этапе или прокликал рандомно, если интерес к сервису еще не угас).
просмотр самих роликов тоже оставил непонятное ощущение: при нажатии на ролик, сайт начинает что-то долго-долго грузить. но хотя бы прогресс-бар есть, зелененький :). я было подумал, что он грузит весь ролик ко мне. ну чтобы проигрывать без пауз и тп. но нет — после загрузки, ролик играется с регулярными паузами на дозагрузку.
вообщем, впечатление осталось непонятное. то ли сервис чем-то перегружен, то ли что.
да и с цветовой гаммой что-то нужно сделать: очень сложно понять, в каком же поле ввода находится курсор. про другое не скажу, меня хватило только на битву с регистрацией и попытку что-то посмотреть.
Почитал комментарии к приложению на маркете, решил попробовать.
Подскажите пожалуйста, зачем приложению разрешения кроме доступа в интернет?
с гпс еще более-менее понятно, но вот платные вызовы вызывают непонимание.
«Платные услуги
осуществление телефонных вызовов
Приложение сможет автоматически осуществлять исходящие вызовы. Вредоносные приложения получат возможность осуществлять нежелательные вызовы. Это разрешение не позволяет приложению совершать вызовы служб экстренной помощи.»
Вот чего бы им нормальное mmc-то не сделать? :)
а так, получается нет особой разницы — что кроме mmc-консоли запускать vclient к сферам, что бумеранг. все равно куча окон.
(если у вас несколько vcenter, vclient можно запускать батником с параметром подключения к нужному серверу: www.firetooth.net/confluence/display/public/VMware+-+vSphere+client )
«Потеря информации во время разворачивания базы или передвижения ее между серверами»
а можно чуть подробнее раскрыть сценарий этих передвижений?
насколько я понимаю, должно иметься в виду что-то отличное от штатных механизмов move db, copy db — т.к. они предлагают «движение» и связанных объектов (логины, задания и тд). по крайней мере, если делать это через гуй.
с логинами/паролями вопрос примерно тот же: имеются в виду способы авторизации по SQL/внутреннему механизму бд? или имеется в виду, что доменный аккаунт на новом сервере может «не попасть» в нужные группы безопасности SQL?
«Процедура sp_migrate_user_to_contained нужна для миграции пользователей в автономную базу»
а как у этом случае будет протекать авторизация одноименных пользователей на сервере/в бд1/в бдН?
т.е. имеем 2+ «унаследованных» баз, базы раньше жили на отдельных серверах, везде был сделан вход через «sa», пароли sa разные.
сможет ли приложение прозрачно аутентифицироваться/авторизоваться под sa своей базы?
вытекающий вопрос: если мы мигрируем БД с сервера на сервер, и на новом сервере в списке учеток сервера/автономных бд уже есть аккаунт с таким же именем — что будет?
«И не забывайте про уведомления. Вы должны ежеутренне приходя на работу видеть сводку ночных бэкапов в сжатом и толковом виде, а не лазить по серверам и их консолям полчаса, выясняя где что и как отработало»
используется ли у вас какое-то автоматическое отслеживание таких сообщений?
ведь иногда, бэкап может не просто отработать с ошибкой, а не отработать вообще и/или не прислать отчет — и такие ситуацию явно надо как-то отслеживать не руками. особенно, когда систем несколько.
а как вы управляете расписанием резервного копирования?
например, есть 3 файловых сервера, есть 1 сервер под бэкапы. если изначально настроить расписание из предположения что каждый ФС будет обрабатываться 2 часа, и поставить в расписание их с интервалом в 2,5-3 — в какой-то момент бэкапы могут «наложиться». что либо просто приведет их длительному выполнению, либо к сбою в итоге.
а если бэкап-серверов и источников много — уже явно не получится обойтись простым расписанием «назначенных задач». т.к. нужен и полный список заданий и штатное время выполнения и объем и прочая.
mittel, а есть ли в вашей схеме т.н. «общие ящики/емылы»?
т.е. некоторые адреса, почту которых должны получать сразу несколько сотрудников и/или иметь возможность отправлять от имени этого общего емыла.
интересно было бы узнать, по какому варианту вы пошли: почтовый ящик, группа, еще как-то.
если ящик и добавляемый как дополнительный, то как решили проблему сохранения отправляемых писем в нем?
если группа, то как ведется архив и доступ к архиву полученной/отправленной почты таких емылов?
как пример: hr@company.ru. могут как просто получать все эйчары, так и быть ящик, куда валится весь входящий спам. а сам ящик подключен у пользователей (и права full+send as).
до outlook 2010, отправляемая почта кладется в основной ящик пользователя. и на наших почтовиках сделаны хитрые правила, чтобы класть ее обратно. в 2010 ситуация гороздо лучше — аутлюк научился подключаться несколько учеток экса в один профиль. но может быть можно решить вопрос и без него?
и вопрос по конкретной системе: у вас насколько я понял, экс 2007. используется ли у вас архивирование почтовой переписки? если да, то штатным механизмом экса или транспортными правилами или как-то еще?
а почему нельзя совместить оба варианта? если есть как персонализированные ПК, так и «общедоступные» логично вторые именовать иначе. и юзеров пускать под своими собственными логинами.
я в этот пост пару дней назад примерно такой коммент-вопрос хотел написать — разделение личных и общих ПК.
возможно, вашим телеграфистам нужно использовать «общие документы» или есть еще какие-то сложности против того, чтобы комп назвать общим и каждому сотруднику сделать личную учетку?
перечитал свой коммент — действительно как-то резковато получилось. прошу прощения.
тема несколько зацепила :)
«мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами»
не совсем так. с тем, что собирать «по кирпичикам» гораздо правильнее и надежнее, я с вами абсолютно согласен. только вот когда движуха персонала человек 10 в месяц и больше — на кирпичики уходит неприлично много времени. да и риск ошибок возрастает. (хотя конечно, если в конторе со 100 человеками 5+ админов, это смешные цифры. а если 1-2...)
плюс, опять же, если структура конторы меняется каждые полгода, перепахивать права на каждом юзвере по отдельности — еще та задачка. даже если раз в год — неделя обычно выкинута на изменения и устранения косяков. даже если членство в группах менять не руками, а через скрипты.
плюс, просто может быть у меня не было такого, чтобы 1 бух мог работать с 1с, а другой такой же нет. т.е. внутри отдела/группы отдела, функционал был одинаковый.
что же касается «индивидуальных прав» — группы «бух зп», «бух ос» и тд. и есть те самые нужые права из «множества, доступных отделу/департаменту». например, у вас 3 расчетчика, 3 на ОС и тд. весьма маловероятно, что один расчетчик будет ходить на терминал, а другой работать с ПК. аналогично и с другими.
если отвлечься от бухов, возьмем например, «сметчик» и «сметчик выездной». можно набрать «по кирпичикам» права каждому сотруднику (СПО, ФС, БД, РДП/ВПН, НОУТ), а можно наполнить обе роли и конкретному сотруднику дать одну из них. или сделать роли дополняющими: «сметчик» + «мобильный сотрудник».
при первом варианте мы даже сможем легко давать отчет руководству «сколько у нас мобильных сотрудников такого-то отдела» и тп. при втором варианте, ответить тоже сможем, но уже нужно будет искать пересечение множеств.
и таки да, тут уже общего рецепта точно не будет.
и к вопросу о «кирпичиках», «сб» и тд — может быть вы отдельным постом осветите процесс изменения? т.е. те самые вопросы по «добавлению/удалению кирпичиков» людям, автоматизированность применения изменений на ПК/серверах (см. коммент ниже про «убрать ярлык») и тп. мне почему-то кажется, что при таком подходе у вас эта штука должна быть очень четко проработанной. и скорее всего, расхождение взглядов на группы связано именно с протеканием процессов изменений.
«назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд»
конторы бывают разные. почему 3+ уровня? например, есть куча департаментов, есть куча отделов, есть куча проектов. сделать «сразу хорошо», отделив проекты от отделов не всегда получается. в внутрь отделов/проектов нужно давать доступ сотрудникам других подразделений.
хотя конечно да, если как у вас, руководство положительно смотрит на правильную организацию хранения, такие права и не требуются.
«Тут единого рецепта наверное нет»
почему я упомянул скрипты как нежелательное — написание скриптов это уже оттенок программизма. соответственно, нужно чтобы админ имел и опыт скриптописания и желание возиться со скриптами. а при смене админов, это получается далеко не всегда. (опять же, вопрос движения персонала)
и в отличие от скриптов, показать инструкцию/доку от софтины гораздо проще и надежнее.
(и, кстати, отдельной стезей идет «самописное ПО, которое пишется отцом-основателем» и ситуация когда «отец-основатель» уходит из конторы. в лучшем случае, ПО просто перестает развиваться...)
«когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS»
в принципе согласен, если СПО не кривое, то вполне можно.
«Это уже не «небольшие организации».»
ммм… как сказать. вот скажем, есть контора. покупает другую контору. в присоединяемой организации обычно уже есть свое ИТ-хозяйство. если присоединяется не одна, а несколько контор, то и доменов уже становится несколько. и вариантов становится два: или все конторы вводить в основной лес/домен или настраивать связи между ними. если же ИТ новой конторы остается самостоятельным, то остается только второй вариант — проще дать указания по обеспечению связи, чем разгребать внутреннюю сеть.
и так да, речь о конторах меньше 500 человек, связанных с компами :)
зы: если что, это не критика, это скорее желание понять причины принятых решений, их плюсы и минусы для дальнейшего использования.
ззы: а на тему СКС/каналов связи у вас планируется пост-другой? было бы интересно почитать, особенно, если решения вырабатывались в процессе переездов внутри здания/в другие здания и тд.
«В результате, чтобы пустить кого-то на сервер 1С, достаточно добавить его в группу»
как уже правильно заметили, создавать группу по каждому чиху тоже может стать накладно.
может быть я невчитался в статью, но не увидел рекомендации создания групп по ролям.
например, те же бухи, которые ходят по рдп на терминал с 1с: создав группы FLD_1c и RDP_1c, на мой взгляд логичнее добавить группу «Бухгалтерия» и включить обе эти группы туда. а самих пользователей уже банально добавлять в «Бухгалтерия». плюс, не надо думать «а какой же группой у нас ставится RDP-ярлычок?», «а какой же группой даются права на SQL?» и прочая прочая.
получается простая схема: есть отдел, есть функционал отдела — есть группа отдела. приходит человек — попадает в группу отдела и имеет щастье.
«А еще лучше прямо запуск самой 1С делать через такой скрипт»
кстати о скриптах — я уже давно для себя решил, что чем меньше скриптов и чем больше готовых решений используется, тем меньше проблем. начиная с такой мелочи, как «ушел человек, который писал этот скрипт полжизни». касательно конкретно 1с — 7рка отлично настраивается через политики с реестром, 8рка — через плагин к AD, который так же через GPO прописывает нужные базы. и опять задача сводится к «пришел дцатый бух, добавили его в группу бухов и группу бухов по функицоналу (ЗП, ОС и тд)». бух запустил комп — все нужное есть сразу.
с другими шедеврами «программизма» конечно сложнее. особенно с поделками, которые хотят админские права и писать исключительно в C:. но это уже отдельный разговор. (и таки да, к сожалению, эти шедевры стоят денег и там низкая конкуренция).
касаемо ярлычков, принтеров и прочая — с приходом GPP потребность в скриптах практически свелась к нулю. а настроить рабочий стол, на мой взгляд, гораздо более правильно через стандартный профиль. в этом случае, опять же, достаточно просто скопировать профиль и поправить права на скопированном. дальше юзверь грузится и засасывает готовый профиль с сервера.
«Например группы которые используются для разрешения доступа к папкам можно называть так FLD_FolderName_RW»
кстати, было бы интересно посмотреть на схему таких групп, когда права на ресурсы назначаются на 3+ уровней вглубь дерева папок. например, «депаратамент — отдел — группа — проекты». у меня получалась уж очень сложная схема. хотя это и было лучше, чем назначать права на папки ручками. плюс, возник такой ньюанс — если называть группы осмысленно, по названиям папок, в какой-то момент упираемся в ограничение на длину имени группы. (группы создавались автоматом, на основе дерева шары)
опять же, предложенная схема «FLD_Foldername» явно заточена под то, что все ресурсы лежат в одном корне DFS? а какие решения были выработаны для случаев, когда права нужно давать на конкретном сервере? или если в лесу несколько доменов/несколько лесов (подразделения/афф конторы)?
«Я не буду вдаваться глубоко в теорию и рассказывать об универсальных, глобальных локальных группах — желающие все подробности смогут найти в документации, благо ее предостаточно»
наверное, стоит немного упомянуть об их функционале? все-таки, если организация работает в одной локалке это одно, а если подразделений по регионам кучка — вопрос групп уже может стать острым. и дело даже не в трафике репликации. а банальной скорости доступа к объектам и тп.
и вы таки хотите сказать, что _сервер_ позволит удалить его открытые файлы?
может быть тогда стоит задуматься о смене mysql на что-то нормальное, что не позволяет таких фокусов?
а по существу: «дропнули базу в продакшене? меняем работу и больше НИКОГДА не тестимся на продакшн базах».
если бэкапы БД делаются нормально (ежечасно или чаще), даже почка останется при себе :)
еще более по существу: перед обновлением чего-либо учимся делать бэкап и проверять, что из него можно подняться. бэкап может быть как в виде бэкапа, так и в виде отключенного «запасного сервера» (зеркало и тп).
«есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д.»
а можно этот момент осветить чуть подробнее: с какими проблемами восстановления приходилось сталкиваться?
может быть даже в виде отдельной статьи, ведь скорее всего систем и «заморочек» было много?
используется ли в вашей инфраструктуре несколько exchange серверов и приходилось ли восстанавливать первый/рядовой экс? были ли проблемы связанные с AD (сайтами) или с чем-то еще?
делались ли оптимизации для поднятия SQL-серверов? (когда базы по дцать гигов и их кучка, поднятие всего требует времени. а «работать уже хотят все и сразу») опять же, когда баз много и они большие, возникает вопрос схемы резервного копирования — в случае SQL речь уже идет не только о самой БД, но и о логах. которые тоже любят расти/обрезаться.
делалась ли на каких-либо сервисах оптимизация схемы резервного копирования в пользу времени восстановления, вместо места под бэкапы? (например, тот же экс судя по предыдущему посту должен быть весьма нетривиален по времени восстановления. особенно, если сторы большие и их мало)
действительно ли оказалось выгоднее иметь несколько ежедневных диффов вместо shadow copy на файловых хранилищах? может быть в процессе эксплуатации выявлены какие-то проблемы, мешающие полноценному использованию теневых копий?
можно ли по заголовку поста «про бэкапы» считать, что здесь рассмотрен именно аспект сохранения данных, а не обеспечения непрерывности работы? хотелось бы почитать как сделана именно непрерывность :) особенно, если полноценно перешли на экс 2007 (про SQL к сожалению поста еще не было, но если есть и SQL 2005+ — тоже интересно, используется ли зеркалирование/standbay и тп. в первую очередь, правда, с точки зрения непрерывности.)
ну и уже отвлеченный вопрос: поднятие упавшего сервиса выполняется руками или автоматизированно какой-то системой? например, если упал SQL, на который завязан sharepoint. или FS + DC и тп.
как реализовано восстановление системных объектов? т.е. если удаляем учетку в DC, поднимается ли она из какого-то бэкапа спецсофтом или ручками вынимается из захоронения и настраивается в первоначальный вид руками. вопрос больше по связанным сервисам, т.к. одного только SID не всегда достаточно (взять тот же экс)
Может быть имелась в виду схема имен?
т.е. по умолчанию DFS создается не-FQDN. После небольшой правки реестра, ресурсы DFS принудительно прописываются как FQDN. Например, \\company\ROOT -> \\company.local\ROOT.
Соответственно, снимается проблема разрешения «коротких» имен и доступа к ресурсам.
Автономные папки же, очень не рекомендуется включать с общими ресурсами. Но вот с папками пользователя (мои документы/рабочий стол) вкупе с их перенаправлением на сервер, получается весьма удобно для случаев порчи ноутов в поездках. Если этого не делать, возникает очень острый вопрос резервной копии данных юзера.
В данном случае, скорее главенствует не количество постов в блоге.
Верноятнее, блогочтение воспринимается как нечто "необязательное, может быть сделаю". И тогда вопрос "количества постов" не стоит чтение не приносит ничего, кроме траты времени.
Если же чтение приносит информацию/ощущения количество постов не решает. Решает интересность, полезность, etc. И лично я бы разделил подписки по уровню важности самые важные вначале, менее важные в конце. Т.е. обычный принцип управления своим временем.
В своей подписке я так и поступил все фиды разбиты по группам 10, 20,.., 90 (с подпунктами). Далее просто идешь "сверху вниз". если не хватило времени на "неважное" оно осталось непрочитанным. Если хватило прочитал.
(кстати, в случае гугляридера очень помогает использование пробела либо фокус переходит на следующий пост, либо в следующий раздел/группу)
зы: кстати, некоторые разделы имеют "100+" сообщений в день, но читаются за 5-10 минут. потому что носят, скорее, "обзорный характер". а разделы с 1-10 постов заставляют вчитываться в статьи...
Сейчас же, в свете выхода машинок на WP8, возникает вопрос: планируется ли аналогичный девайс, но уже на основе WP8?
Или пока еще рано говорить о планшетизации именно WP8 из-за позиционирования WinRT как ОС для планшетов?
www.ivi.ru/plus/
его только нужно чуть-чуть изменить: при распределении подписки, брать полное время «просмотров». и каждому фильм/ролику отчислять кусочек подписки пропорционально времени просмотра.
т.е. если пользователь посмотрел за месяц 3 фильма по 2 часа и 1 ролик на 5 минут, фильмам уйдет ( 10уе * 120/365 ). ролику — (10уе * 5/365).
причем, в эту схему укладывается и «уход с просмотра» — начал смотреть фильм, не понравилось — выключил. в зачет фильму пошли не 2 часа, а первые несколько минут. с «растянутыми» роликами аналогично — перемотка же не будет временем просмотра.
ps: да, речь про онлайн просмотр. если позволять «оффлайн», нужно или заморачиватьс с оффлайн подсчетом времени просмотра или тупо зачитывать всю длительность.
pps: вообщем-то эту схему явно можно применить и к музыке и тд.
потом на границе видимости обнаруживается полоска-прогрессбар, которая еле ползет.
думаю, гораздо удобнее было бы видеть картинку-фон «Подождите, загружается интерфейс» или что-то подобное. а не просто пустую страницу с серым фоном.
(ну и само собой, какую-нибудь надпись для случаев повышенных настроек безопасности — если убрать домен из зоны «доверенных», открывается просто пустая страница)
Саму регистрацию пройти сложно из-за города.
да и вообще не совсем понятно, зачем вводить персональную информацию сразу, при регистрации.
после регистрации, пришло письмо, открыл ссылку. открылся сайт. т.к. никаких надписей про «вы прошли активацию» и тп не увидел, внимательно смотрел на страницу. обнаружил в самом верху нижнюю часть стрелочки ">". ради интереса нажал — оказалось, это продолжение активации.
после ввода емыла (зачем? код активации же уникален для пользователя?), открылся попап с требованием заполнить кучу персональной информации. прокликал, т.к. не вижу смысла вводить инфу до знакомства с сервсисом. да и сервис не затребовал вводить что-либо. (если бы затребовал, точно закрыл бы уже на этом этапе или прокликал рандомно, если интерес к сервису еще не угас).
просмотр самих роликов тоже оставил непонятное ощущение: при нажатии на ролик, сайт начинает что-то долго-долго грузить. но хотя бы прогресс-бар есть, зелененький :). я было подумал, что он грузит весь ролик ко мне. ну чтобы проигрывать без пауз и тп. но нет — после загрузки, ролик играется с регулярными паузами на дозагрузку.
вообщем, впечатление осталось непонятное. то ли сервис чем-то перегружен, то ли что.
да и с цветовой гаммой что-то нужно сделать: очень сложно понять, в каком же поле ввода находится курсор. про другое не скажу, меня хватило только на битву с регистрацией и попытку что-то посмотреть.
PS: провайдер Билайн, тариф 15мбит днем. ОС Win7, IE9.
Подскажите пожалуйста, зачем приложению разрешения кроме доступа в интернет?
с гпс еще более-менее понятно, но вот платные вызовы вызывают непонимание.
«Платные услуги
осуществление телефонных вызовов
Приложение сможет автоматически осуществлять исходящие вызовы. Вредоносные приложения получат возможность осуществлять нежелательные вызовы. Это разрешение не позволяет приложению совершать вызовы служб экстренной помощи.»
а так, получается нет особой разницы — что кроме mmc-консоли запускать vclient к сферам, что бумеранг. все равно куча окон.
(если у вас несколько vcenter, vclient можно запускать батником с параметром подключения к нужному серверу: www.firetooth.net/confluence/display/public/VMware+-+vSphere+client )
а можно чуть подробнее раскрыть сценарий этих передвижений?
насколько я понимаю, должно иметься в виду что-то отличное от штатных механизмов move db, copy db — т.к. они предлагают «движение» и связанных объектов (логины, задания и тд). по крайней мере, если делать это через гуй.
с логинами/паролями вопрос примерно тот же: имеются в виду способы авторизации по SQL/внутреннему механизму бд? или имеется в виду, что доменный аккаунт на новом сервере может «не попасть» в нужные группы безопасности SQL?
«Процедура sp_migrate_user_to_contained нужна для миграции пользователей в автономную базу»
а как у этом случае будет протекать авторизация одноименных пользователей на сервере/в бд1/в бдН?
т.е. имеем 2+ «унаследованных» баз, базы раньше жили на отдельных серверах, везде был сделан вход через «sa», пароли sa разные.
сможет ли приложение прозрачно аутентифицироваться/авторизоваться под sa своей базы?
вытекающий вопрос: если мы мигрируем БД с сервера на сервер, и на новом сервере в списке учеток сервера/автономных бд уже есть аккаунт с таким же именем — что будет?
я всегда считал, что правильная ОС контролирует необходимые ей ресурсы.
«Сначала изучите ОС»
буду рад получить от вас ссылку, описывающую поведение ОС в данной ситуации. почитаю с удовольствием.
используется ли у вас какое-то автоматическое отслеживание таких сообщений?
ведь иногда, бэкап может не просто отработать с ошибкой, а не отработать вообще и/или не прислать отчет — и такие ситуацию явно надо как-то отслеживать не руками. особенно, когда систем несколько.
а как вы управляете расписанием резервного копирования?
например, есть 3 файловых сервера, есть 1 сервер под бэкапы. если изначально настроить расписание из предположения что каждый ФС будет обрабатываться 2 часа, и поставить в расписание их с интервалом в 2,5-3 — в какой-то момент бэкапы могут «наложиться». что либо просто приведет их длительному выполнению, либо к сбою в итоге.
а если бэкап-серверов и источников много — уже явно не получится обойтись простым расписанием «назначенных задач». т.к. нужен и полный список заданий и штатное время выполнения и объем и прочая.
т.е. некоторые адреса, почту которых должны получать сразу несколько сотрудников и/или иметь возможность отправлять от имени этого общего емыла.
интересно было бы узнать, по какому варианту вы пошли: почтовый ящик, группа, еще как-то.
если ящик и добавляемый как дополнительный, то как решили проблему сохранения отправляемых писем в нем?
если группа, то как ведется архив и доступ к архиву полученной/отправленной почты таких емылов?
как пример: hr@company.ru. могут как просто получать все эйчары, так и быть ящик, куда валится весь входящий спам. а сам ящик подключен у пользователей (и права full+send as).
до outlook 2010, отправляемая почта кладется в основной ящик пользователя. и на наших почтовиках сделаны хитрые правила, чтобы класть ее обратно. в 2010 ситуация гороздо лучше — аутлюк научился подключаться несколько учеток экса в один профиль. но может быть можно решить вопрос и без него?
и вопрос по конкретной системе: у вас насколько я понял, экс 2007. используется ли у вас архивирование почтовой переписки? если да, то штатным механизмом экса или транспортными правилами или как-то еще?
я в этот пост пару дней назад примерно такой коммент-вопрос хотел написать — разделение личных и общих ПК.
возможно, вашим телеграфистам нужно использовать «общие документы» или есть еще какие-то сложности против того, чтобы комп назвать общим и каждому сотруднику сделать личную учетку?
тема несколько зацепила :)
«мне лично не очень нравится. т.к. вы создаете группу, обладающую «множество прав», в которое потом вводите туда всех кто приблизительно должен обладать этими правами»
не совсем так. с тем, что собирать «по кирпичикам» гораздо правильнее и надежнее, я с вами абсолютно согласен. только вот когда движуха персонала человек 10 в месяц и больше — на кирпичики уходит неприлично много времени. да и риск ошибок возрастает. (хотя конечно, если в конторе со 100 человеками 5+ админов, это смешные цифры. а если 1-2...)
плюс, опять же, если структура конторы меняется каждые полгода, перепахивать права на каждом юзвере по отдельности — еще та задачка. даже если раз в год — неделя обычно выкинута на изменения и устранения косяков. даже если членство в группах менять не руками, а через скрипты.
плюс, просто может быть у меня не было такого, чтобы 1 бух мог работать с 1с, а другой такой же нет. т.е. внутри отдела/группы отдела, функционал был одинаковый.
что же касается «индивидуальных прав» — группы «бух зп», «бух ос» и тд. и есть те самые нужые права из «множества, доступных отделу/департаменту». например, у вас 3 расчетчика, 3 на ОС и тд. весьма маловероятно, что один расчетчик будет ходить на терминал, а другой работать с ПК. аналогично и с другими.
если отвлечься от бухов, возьмем например, «сметчик» и «сметчик выездной». можно набрать «по кирпичикам» права каждому сотруднику (СПО, ФС, БД, РДП/ВПН, НОУТ), а можно наполнить обе роли и конкретному сотруднику дать одну из них. или сделать роли дополняющими: «сметчик» + «мобильный сотрудник».
при первом варианте мы даже сможем легко давать отчет руководству «сколько у нас мобильных сотрудников такого-то отдела» и тп. при втором варианте, ответить тоже сможем, но уже нужно будет искать пересечение множеств.
и таки да, тут уже общего рецепта точно не будет.
и к вопросу о «кирпичиках», «сб» и тд — может быть вы отдельным постом осветите процесс изменения? т.е. те самые вопросы по «добавлению/удалению кирпичиков» людям, автоматизированность применения изменений на ПК/серверах (см. коммент ниже про «убрать ярлык») и тп. мне почему-то кажется, что при таком подходе у вас эта штука должна быть очень четко проработанной. и скорее всего, расхождение взглядов на группы связано именно с протеканием процессов изменений.
«назначать доступ на папки которые 3+ уровня вниз — это как-то перебор на мой взгляд»
конторы бывают разные. почему 3+ уровня? например, есть куча департаментов, есть куча отделов, есть куча проектов. сделать «сразу хорошо», отделив проекты от отделов не всегда получается. в внутрь отделов/проектов нужно давать доступ сотрудникам других подразделений.
хотя конечно да, если как у вас, руководство положительно смотрит на правильную организацию хранения, такие права и не требуются.
«Тут единого рецепта наверное нет»
почему я упомянул скрипты как нежелательное — написание скриптов это уже оттенок программизма. соответственно, нужно чтобы админ имел и опыт скриптописания и желание возиться со скриптами. а при смене админов, это получается далеко не всегда. (опять же, вопрос движения персонала)
и в отличие от скриптов, показать инструкцию/доку от софтины гораздо проще и надежнее.
(и, кстати, отдельной стезей идет «самописное ПО, которое пишется отцом-основателем» и ситуация когда «отец-основатель» уходит из конторы. в лучшем случае, ПО просто перестает развиваться...)
«когда ресурсы лежат на конкретном сервере, то почему бы не ввести эти ресурсы в DFS»
в принципе согласен, если СПО не кривое, то вполне можно.
«Это уже не «небольшие организации».»
ммм… как сказать. вот скажем, есть контора. покупает другую контору. в присоединяемой организации обычно уже есть свое ИТ-хозяйство. если присоединяется не одна, а несколько контор, то и доменов уже становится несколько. и вариантов становится два: или все конторы вводить в основной лес/домен или настраивать связи между ними. если же ИТ новой конторы остается самостоятельным, то остается только второй вариант — проще дать указания по обеспечению связи, чем разгребать внутреннюю сеть.
и так да, речь о конторах меньше 500 человек, связанных с компами :)
зы: если что, это не критика, это скорее желание понять причины принятых решений, их плюсы и минусы для дальнейшего использования.
ззы: а на тему СКС/каналов связи у вас планируется пост-другой? было бы интересно почитать, особенно, если решения вырабатывались в процессе переездов внутри здания/в другие здания и тд.
как уже правильно заметили, создавать группу по каждому чиху тоже может стать накладно.
может быть я невчитался в статью, но не увидел рекомендации создания групп по ролям.
например, те же бухи, которые ходят по рдп на терминал с 1с: создав группы FLD_1c и RDP_1c, на мой взгляд логичнее добавить группу «Бухгалтерия» и включить обе эти группы туда. а самих пользователей уже банально добавлять в «Бухгалтерия». плюс, не надо думать «а какой же группой у нас ставится RDP-ярлычок?», «а какой же группой даются права на SQL?» и прочая прочая.
получается простая схема: есть отдел, есть функционал отдела — есть группа отдела. приходит человек — попадает в группу отдела и имеет щастье.
«А еще лучше прямо запуск самой 1С делать через такой скрипт»
кстати о скриптах — я уже давно для себя решил, что чем меньше скриптов и чем больше готовых решений используется, тем меньше проблем. начиная с такой мелочи, как «ушел человек, который писал этот скрипт полжизни». касательно конкретно 1с — 7рка отлично настраивается через политики с реестром, 8рка — через плагин к AD, который так же через GPO прописывает нужные базы. и опять задача сводится к «пришел дцатый бух, добавили его в группу бухов и группу бухов по функицоналу (ЗП, ОС и тд)». бух запустил комп — все нужное есть сразу.
с другими шедеврами «программизма» конечно сложнее. особенно с поделками, которые хотят админские права и писать исключительно в C:. но это уже отдельный разговор. (и таки да, к сожалению, эти шедевры стоят денег и там низкая конкуренция).
касаемо ярлычков, принтеров и прочая — с приходом GPP потребность в скриптах практически свелась к нулю. а настроить рабочий стол, на мой взгляд, гораздо более правильно через стандартный профиль. в этом случае, опять же, достаточно просто скопировать профиль и поправить права на скопированном. дальше юзверь грузится и засасывает готовый профиль с сервера.
«Например группы которые используются для разрешения доступа к папкам можно называть так FLD_FolderName_RW»
кстати, было бы интересно посмотреть на схему таких групп, когда права на ресурсы назначаются на 3+ уровней вглубь дерева папок. например, «депаратамент — отдел — группа — проекты». у меня получалась уж очень сложная схема. хотя это и было лучше, чем назначать права на папки ручками. плюс, возник такой ньюанс — если называть группы осмысленно, по названиям папок, в какой-то момент упираемся в ограничение на длину имени группы. (группы создавались автоматом, на основе дерева шары)
опять же, предложенная схема «FLD_Foldername» явно заточена под то, что все ресурсы лежат в одном корне DFS? а какие решения были выработаны для случаев, когда права нужно давать на конкретном сервере? или если в лесу несколько доменов/несколько лесов (подразделения/афф конторы)?
«Я не буду вдаваться глубоко в теорию и рассказывать об универсальных, глобальных локальных группах — желающие все подробности смогут найти в документации, благо ее предостаточно»
наверное, стоит немного упомянуть об их функционале? все-таки, если организация работает в одной локалке это одно, а если подразделений по регионам кучка — вопрос групп уже может стать острым. и дело даже не в трафике репликации. а банальной скорости доступа к объектам и тп.
и вы таки хотите сказать, что _сервер_ позволит удалить его открытые файлы?
может быть тогда стоит задуматься о смене mysql на что-то нормальное, что не позволяет таких фокусов?
а по существу: «дропнули базу в продакшене? меняем работу и больше НИКОГДА не тестимся на продакшн базах».
если бэкапы БД делаются нормально (ежечасно или чаще), даже почка останется при себе :)
еще более по существу: перед обновлением чего-либо учимся делать бэкап и проверять, что из него можно подняться. бэкап может быть как в виде бэкапа, так и в виде отключенного «запасного сервера» (зеркало и тп).
а можно этот момент осветить чуть подробнее: с какими проблемами восстановления приходилось сталкиваться?
может быть даже в виде отдельной статьи, ведь скорее всего систем и «заморочек» было много?
используется ли в вашей инфраструктуре несколько exchange серверов и приходилось ли восстанавливать первый/рядовой экс? были ли проблемы связанные с AD (сайтами) или с чем-то еще?
делались ли оптимизации для поднятия SQL-серверов? (когда базы по дцать гигов и их кучка, поднятие всего требует времени. а «работать уже хотят все и сразу») опять же, когда баз много и они большие, возникает вопрос схемы резервного копирования — в случае SQL речь уже идет не только о самой БД, но и о логах. которые тоже любят расти/обрезаться.
делалась ли на каких-либо сервисах оптимизация схемы резервного копирования в пользу времени восстановления, вместо места под бэкапы? (например, тот же экс судя по предыдущему посту должен быть весьма нетривиален по времени восстановления. особенно, если сторы большие и их мало)
действительно ли оказалось выгоднее иметь несколько ежедневных диффов вместо shadow copy на файловых хранилищах? может быть в процессе эксплуатации выявлены какие-то проблемы, мешающие полноценному использованию теневых копий?
можно ли по заголовку поста «про бэкапы» считать, что здесь рассмотрен именно аспект сохранения данных, а не обеспечения непрерывности работы? хотелось бы почитать как сделана именно непрерывность :) особенно, если полноценно перешли на экс 2007 (про SQL к сожалению поста еще не было, но если есть и SQL 2005+ — тоже интересно, используется ли зеркалирование/standbay и тп. в первую очередь, правда, с точки зрения непрерывности.)
ну и уже отвлеченный вопрос: поднятие упавшего сервиса выполняется руками или автоматизированно какой-то системой? например, если упал SQL, на который завязан sharepoint. или FS + DC и тп.
как реализовано восстановление системных объектов? т.е. если удаляем учетку в DC, поднимается ли она из какого-то бэкапа спецсофтом или ручками вынимается из захоронения и настраивается в первоначальный вид руками. вопрос больше по связанным сервисам, т.к. одного только SID не всегда достаточно (взять тот же экс)
т.е. по умолчанию DFS создается не-FQDN. После небольшой правки реестра, ресурсы DFS принудительно прописываются как FQDN. Например, \\company\ROOT -> \\company.local\ROOT.
Соответственно, снимается проблема разрешения «коротких» имен и доступа к ресурсам.
Автономные папки же, очень не рекомендуется включать с общими ресурсами. Но вот с папками пользователя (мои документы/рабочий стол) вкупе с их перенаправлением на сервер, получается весьма удобно для случаев порчи ноутов в поездках. Если этого не делать, возникает очень острый вопрос резервной копии данных юзера.
Забудем про морзянку, про телетайпы, про модемы и т.д..
Идея передачи информации за счет звуковых колебаний не нова. И давно обсосана.
5 лет => 240 * 5 = 1200 уе.
вы хотите сказать, что тонкий клиент стоит больше штуки баксов?
как уже сказано, это фактически и есть тонкий клиент. правда, скорее консоль, нежели чем полноценный клиент.
Верноятнее, блогочтение воспринимается как нечто "необязательное, может быть сделаю". И тогда вопрос "количества постов" не стоит чтение не приносит ничего, кроме траты времени.
Если же чтение приносит информацию/ощущения количество постов не решает. Решает интересность, полезность, etc. И лично я бы разделил подписки по уровню важности самые важные вначале, менее важные в конце. Т.е. обычный принцип управления своим временем.
В своей подписке я так и поступил все фиды разбиты по группам 10, 20,.., 90 (с подпунктами). Далее просто идешь "сверху вниз". если не хватило времени на "неважное" оно осталось непрочитанным. Если хватило прочитал.
(кстати, в случае гугляридера очень помогает использование пробела либо фокус переходит на следующий пост, либо в следующий раздел/группу)
зы: кстати, некоторые разделы имеют "100+" сообщений в день, но читаются за 5-10 минут. потому что носят, скорее, "обзорный характер". а разделы с 1-10 постов заставляют вчитываться в статьи...
(жалко, плюса добавить не могу...)