Опубликовано по просьбе хорошего человека fcserg, так что прошу карму форвардить ему

Перед многими из нас часто возникают задачи типа «развернуть много рабочих станций», причем железо на всех этих станциях может быть разное. Мало того, на некоторых из этих машинах должен быть предустановлен разнообразный софт (от «корпоративных наборов» — аська, браузеры, pdf-читалки, до «университетских» наборов – Visual Studio, Project Manager). Раньше для таких целей использовался RIS (Remote Installation Services), теперь Microsoft агитирует за WDS (Windows Deployment Services). Мы остановимся именно на последнем.

В компаниях-дистрибьюторах Проктэр энд Гэмбл есть простой и довольно эффективный алгоритм для написания коммерческих предложений. Он не безупречен, зато ему можно научиться всего за несколько дней. Этот подход часто хорошо подходит и для других документов — от служебных записок до деловых писем.

Алгоритм включает в себя 5 шагов:

1. Описание исходной ситуации.

• Ориентирует, к чему, собственно, относится предложение.
• Служит предпосылкой, исходными данными для логического обоснования предложения.
• Показывает клиенту, что КП написано персонально.
• Провоцирует «да-реакцию».

Важно очень коротко, в нескольких предложениях описать только те вещи, которые имеют отношение к делу. Например, если мы хотим разместить леденцы в прикассовой зоне — то в описании исходной ситуации мы отметим, какой товар сейчас продается в прикассовой зоне, в каких объемах и с какой наценкой.

2. Суть предложения.

• Приковывает внимание; если клиент согласен с предложением, то он будет читать дальше, чтобы узнать подробности и предлагаемые действия; если клиент не согласен — то он захочет выяснить, с чего вдруг это предлагается и зачем ему это надо.
• Позволяет клиенту быстрее понять изложенные дальше преимущества и действия.

Предложение здесь описывается без подробностей, объяснений, оправданий, детализации, амортизации и прочего гламура. Никаких «мы предлагаем совестными усилиями в процессе совместного плодотворного сотрудничества посредством интеграции инфраструктуры управления товарными запасами…»; должно быть просто до примитива, например, «Вы даете нам оперативную информацию о продажах — мы формируем оптимальный заказ» или «В прикассовой зоне вместо презервативов надо продавать наши леденцы».

3. Преимущества для клиента.
Задача этого шага очевидна — нужно замотивировать клиента принять это предложение. Вот здесь уже можно выражаться чуть более дипломатично и многословно. В перечислении преимуществ важно не упустить каких-то вещей, которые кажутся самоочевидными. Например, для вашей компании может подразумеваться, что при поставке товар размещается на стеллажах склада силами ваших сотрудников — для клиента это может быть менее очевидно. Обычно стоит выделить 3—5 преимуществ.

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

5. Первый шаг.
Эту часть часто недооценивают. Что должен сделать клиент в первую очередь, чтобы это КП претворилось в жизнь? Согласовать текст договора? Позвонить вам, если согласен в течение недели? К завтрашнему дню, когда вы обещали позвонить, уточнить со своим логистом возможности перебросок с оказией дополнительных партий по городам области? Надо подумать и спланировать это за клиента.

***

Все это должно влезть меньше, чем на одну страницу. Не нужно сюда пытаться влепить прайс на 500 позиций или любимые цитаты из договора — все это можно вольготно разместить в приложениях.

Предыдущая статья «Обнуление экспертизы программиста при повышении в менеджеры», несмотря на бухтение в коментариях по поводу терминологии «экспертиза» и «опыт», все-таки получила свою долю внимания и обсуждений по делу: тогда продолжаем.

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



И говорим мы не о чем-то простом и легком в плане решений: блинчики или бутерброд на завтрак, кофе с молоком или без на работе. Мы говорим о решениях, за которыми стоят, кроме существенных изменений в жизни еще достаточно существенные усилия, которые нужно приложить.

С этой точки зрения решения, которые касаются выбора профессии и направления, в котором мы строим карьеру — достаточно существенные: как минимум на несколько лет, а то и на десятки лет, мы определяем чем будем заниматься большую часть рабочего времени, с какими задачами будем сталкиваться, с какими проблемами будем иметь дело и вообще будет ли приносить удовольствие то, что вы выберете делать.

Можно выделить ряд чисто «технических» или даже «механических» проблем с принятием решений: это, так сказать, особенности устройства нашего мозга, который пытается уберечь нас от проблем, связанных с изменением состояния. Сейчас — все более-менее понятно, контролируемо, и поэтому мозгу хорошо, а как будет в новом состоянии — непонятно, поэтому плохо. Одна из базовых функций нашего мозга — беречь нас от непонятного, чтобы не стало хуже.

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

Итак, приблизительно с полгода назад, встала задача автоматизировать управление списком баз 1С (коих развелось уже более 20 штук) у пользователей домена.
Делалось это не только удобства ради, но и в рамках проекта по внедрению «ролевой модели доступа». Вкратце, смысл этой модели в том, что каждый пользователь в домене является членом определенной группы (именуемой согласно должности), которая имеет заранее определенный набор привилегий, в том числе и список информационных баз.

Т.к. у нас имеется домен Active Directory, логично использовать групповые политики для выполнения нашей задачи.
Гугление выдавало достаточно много реализаций (и даже платных), но все они, чаще всего, сводились к заранее сформированным файлам со списками баз (ibases.v8i). Нам же хотелось:
a) Централизованно управлять настройками подключения к информационным базам (у нас клиент-серверный вариант с SQL базами).
б) Централизованно управлять списком, доступных пользователю, информационных баз, согласно его «роли».

В итоге я расскажу о решении которое работает уже больше полугода в нашей компании.

Соотносим потребности бизнеса с его возможностями

В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:

• ИТ-сервисах, критичных для бизнеса компании,
• Текущем времени восстановления их работы в случае сбоя,
• Минимально достижимых сроках аварийного восстановления,
• Необходимых ресурсах для их достижения.

И все бы ничего, если бы не ограниченные финансовые возможности организации, не позволяющие приобрести все необходимые резервы для оперативного восстановления. По этой причине заключительная задача планирования аварийного восстановления – поиск баланса между потребностями и финансовыми возможностями бизнеса, и закрепление его в виде соглашения об уровне обслуживания (Service Level Agreement – SLA) в части устранения возникающих инцидентов.

Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия:

Одним из методов сбора информации о процессе является проведение интервью с владельцем или участниками этого бизнес-процесса. Такой традиционный подход встречается очень часто, особенно у начинающих бизнес-аналитиков и матерых консультантов из Big4. Казалось бы очень разумно выслушать человека, формализовать его монолог и согласовать результат с ним же — это быстро и не затратно. Одно плохо — на этапе анализа адекватности результата моделирования деятельности (если такое предусмотрено) происходит отбраковка собранных данных по причине их несогласованности и противоречивости, процедуру сбора данных о ходе процесса надо повторять сначала, «на радость» всем участникам проекта. Почему такое происходит? Как видно из заголовка, дело в респондентах. Ниже на конкретных примерах из личного опыта я покажу, почему был сделан такой вывод и как с этим бороться.

Готовимся к любым падениям

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

Собственно, необходимые ресурсы будут в дальнейшем предметом торга с руководством компании, помогая найти баланс между инвестициями в информационные технологии, временем простоя и потерей данных в случае сбоя. Но это потом, а пока нам нужно определить какие сроки восстановления мы в принципе можем выжать из ИТ-инфраструктуры в случае сбоя. Поехали:

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

Определяем места, где стоит подстелить соломку

Отказы в работе информационных систем – события, которые невозможно исключить полностью. Вне зависимости от причин случившегося сбоя, в момент его возникновения на системного администратора ложится груз ответственности по оперативному восстановлению работоспособности не только ИТ-систем, но и бизнеса в целом.

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

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

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

Задача, которая стоит перед нами, – обеспечить бесперебойную работу и высокую доступность базы данных в клиент-серверном варианте развертывания.
Тип конфигурации — active/passive.

P.S. Вопросы резервирования узлов не относящихся к MSSQL не рассмотрены.

Сейчас на Хабре мало обзоров helpdesk-систем, правда, имеется сравнительный обзор SaaS-helpdesk (с хорошей ссылкой в комментарии от dude1phoenix), обзор OTMS-helpdesk и Request Tracker (как и OTRS написан на Perl).
Предлагаю вам поближе познакомиться с системой поддержки клиентов OTRS, с ее установкой на Debian и интеграцией с Active Directory предприятия.

Накопилась уже внушительная пачка материалов по Windows Server 2012 и Windows Server 2012 R2. Решил для удобства свести все ссылки в один пост. Надеюсь, будет полезно.

Доброго времени суток, Хабр.

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

В этой мини-статье я хочу собрать те нюансы настроек, которые решают эту проблему.

Добрый день.
Очень давно была такая статья как реализовать автоматическое сканирование при нажатии кнопки на сканере, но то ли у меня руки кривые, то ли нежелание детально разбираться, но подвиг автора я повторить не смог. И всё же решил реализовать эту идею по нескольким причинам:
— не отвлекать оператора за АРМ, к которому подключено МФУ;
— ускорить процесс получения электронных копий за счет автоподатчика листов и двухстороннего сканирования.

Подтвердилось существование проблемы, о которой многие догадывались.

Cisco объявили, что неназванный производитель памяти в течение пяти лет (с 2005 по 2010) поставлял им брак. Характер брака: оборудование с этой памятью может годами копить аптайм, не вызывая никаких нареканий к своей работе, но стоит перезагрузить его (по питанию или даже простым reload) — память перестает корректно работать, само устройство либо не загружается, либо загружается и периодически падает. Связано это с деградацией чипов памяти. По заявлению вендора, основные проблемы начинаются после двух лет эксплуатации.

Прежде чем в Cisco полетят тухлые помидоры, спешу предупредить: память стандартная, многие вендоры ее закупали, потому затронуто может быть великое множество единиц оборудования. Есть подтверждение об аналогичных проблемах у Juniper. Но только Cisco сознались, несмотря на неизбежный репутационный ущерб. Их финансовые потери из-за этой катастрофы составляют около 655 миллионов долларов.

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.

Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).

Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.

Оригинал

Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.

IBM Redbook «Introduction to SAN and System Networking»

Начало

По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.

Совсем недавно у меня возникла необходимость создать центральный лог-сервер с веб-интерфейсом и в этой статье я хотел бы поделиться опытом, возможно кому-то он будет полезен. Я опишу установку и настройку веб-просмотрщика логов LogAnalyzer, Rsyslog-клиента, который будет отсылать все логи на удаленный Rsyslog-сервер, и последний, в свою очередь, будет писать их в базу MySQL.

В качестве ОС я выбрал Ubuntu 12.04.

Адреса тестовых вебнод:
192.168.1.51 (loganalyzer-mysql.ip) — Rsyslog-сервер, на этом хосте также будет проинсталлирован LogAnalyzer
192.168.1.50 (loganalyzer-mongo.ip) — Rsyslog-клиент, который будет отсылать логи на сервер loganalyzer-mysql.ip

Настраиваем серверную часть, для чего добавим репозиторий от разработчика Rsyslog:

...
# Adiscon stable repository
deb http://ubuntu.adiscon.com/v7-stable precise/
deb-src http://ubuntu.adiscon.com/v7-stable precise/
...

# apt-key adv --recv-keys --keyserver keyserver.ubuntu.com AEF0CF8E
# gpg --export --armor AEF0CF8E | sudo apt-key add -

Слышали ли вы когда-нибудь в свой адрес упреки в неконструктивности? Может быть, сами кого-то упрекали? Как вы понимаете, что вот это конкретное обсуждение не конструктивно, а вот это конструктивно?

Если начать думать на эту тему, то тут есть на что потратить пару часов. Эту задачу мы сейчас постараемся облегчить. И в рамках нашей серии статей по управленческим инструментам (ушедшей в отпуск на время новогодних праздников), разберем принципы конструктива, предложенные когда-то Энди Гроувом, одним из основателей компании Intel.

Принципы простые, но объясняют довольно много рабочих и не только рабочих конфликтов. И разобравшись с ними вы:

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Здесь не будет полюбившихся нам матриц 2 на 2, но пару схем мы разберем.

За последний год я имел отношения к записи более 1000 лекций разного уровня сложности и хотел бы поделиться своим опытом в этой части. Это обещанное продолжение статьи Тренды в образовательной среде (памятка для вуза).

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

В частности, надо понимать, что ТВ опыт скорее мешает, чем помогает. Мы принципиально набираем операторов без опыта, так как телевизионщики, привыкшие к другой схеме работы, не справляются. Разные планы, разные приоритеты, минимум подсъёмок.

Кроме того, если вы пишете живую, не постановочную, лекцию, то нет возможности снять ещё один дубль. Оператор не имеет права на ошибку. И очень мало можно исправить при монтаже. Зато живая лекция выгодно отличается от постановочной. Лектор забывает о камере, расслаблен, спокоен и работает с привычной аудиторией. Всё это очень хорошо чувствуется при просмотре.

Итак, можно выделить следующие типы видеосъёмки лекций: