Эксплуатационные риски и их минимизация

Преамбула

Всем знакома ситуация, когда на весь зоопарк из компьютеров, ноутбуков, планшетов, копировальной техники, серверов, активного сетевого оборудования и т.д. всего один админ. Он альтруист, вы не подумайте. Он любит свою работу. Он разбирается в теме. Он эффективен и глаза горят. Но как ни крути, когда вся ИТ функция предприятия, пусть даже небольшого, завязана на одного человека – это такой нехилый эксплуатационный риск. Я всегда задаю вопрос: «Что будет, если он, например, заболеет или уволится одним днем без объяснения причин?» Сколько дней вы продержитесь, пока найдете человека, который будет разбираться во всем этом зоопарке с нуля? Нет, ну серьезно? Представьте, что завтра этого человека не будет, а вас закончились лицензии, интернет, бумага в принтере и умер сервер с базой данных клиентов.
(далее…)

Качества лидера

Качества лидера
В одной из своих книг Том Демарко пишет о том, что есть только четыре основных правила менеджмента программных проектов:

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

В другом своем бестселлере он же утверждает: «Неверной оказалась мысль о том, что команды можно заставить кристаллизоваться. Это невозможно. Можно надеяться, что они кристаллизуются, можно стучать по дереву в надежде не сглазить, можно как-то стимулировать повышение вероятности кристаллизации, но невозможно найти универсальный катализатор».

Это не так. На самом деле мысль верная, заставить команду кристаллизоваться возможно и для этого «стучать по дереву» не обязательно.

Универсальным катализатором является лидер. Не бывает лидеров без команд, и я не видел ни одной стоящей команды без лидера.

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

Какими же качествами должен обладать лидер?

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

Ад с учётными записями — почему в одной компании пользователей было в 3 раза больше, чем сотрудников

Прыдстория. В одной производственной компании было около двух десятков(!) кадровых баз. Это базы обособленных подразделений, и в каждой по несколько сотен человек. Всего около 10 тысяч сотрудников. Системный администратор работает грамотный, есть рабочая MS Active Directory.

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

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

В этот момент мы начали работать над внедрением общего решения по управлению учетными записями и правами доступа, IdM. Для начала пришлось избавиться от раздробленности и свести все кадровые базы в одну промежуточную кадровую систему. Её связали с Active Directory через новый центр-репозиторий. Потом подключили к репозиторию остальные бизнес-системы вот так:

Ад с учётными записями — почему в одной компании пользователей было в 3 раза больше, чем сотрудников

Дальше мы удалили все лишние учётки, оставили только действительных сотрудников (заодно увидели пару уволенных, но активно логинящихся). Потом нашли пару очень странных людей… (далее…)

Y55: попытка геймификации счастья

Y55: попытка геймификации счастья

Вместо эпиграфа

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

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

Я хочу поведать об интересной идее, на которую я натолкнулся, о программе Y55: Happiness Trainer. Насколько я понял, название произошло от фразы «why 55», и должно быть универсальным ответом на 55 миллионов ежемесячных запросов в Google «как стать счастливым?».

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

Я не буду пересказывать презентацию, а буду рассказывать я о деталях, которые узнал непосредственно у автора Эрана Шаевича (Eran Shayovich).
(далее…)

О кибервойсках

Где-то с полтора месяца назад наши СМИ трубили об организации в РФ, по подобию у других государств, кибервойск. В МО РФ планировали создавать «научные роты», а к концу 2013г завершить формивание новой структуры, ориентированной на информационную безопасности РФ. Одного моего знакомого очень заинтересовали все эти новости, и он как челеовек отвественный и имеющий, скажем так, непосредственное отношение к специализации «нового» направления, решил уточнить для себя, а теперь, как видите, и не только для себя, некоторые интересовавшие его вопросы. Для это он отправил сообщение в МО РФ следующего вида (оригинал текста): (далее…)

Пол Грэм: Как убедить инвесторов

Август 2013

(Это одно из двух эссе по фандрайзингу. Скоро выйдет следующее по тактике фандрайзинга.)

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

Инвесторы ищут стартапы, которые станут очень успешными. Легко сказать! В стартапах, как и в некоторых других областях, распределение стартапов по степени их успешности подчиняется степенному закону, только в стартапах кривая распределения ещё круче. Очень успешные стартапы настолько успешны, что затмевают собою все остальные. А поскольку число крупных успехов в год можно по пальцем пересчитать (есть мнение, что их в среднем 15 успешных стартапов в год), то инвесторы вообще смотрят на стартапы в чернобелых очках – либо у вас есть шанс стать одним из 15, либо нет. (далее…)

3 причины, почему я никогда не обращусь в студию или большую компанию

Потому что мне дорого обходятся задержки.

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

Так что мне приходится высказывать свои правки как минимум менеджеру(1 шаг до специалиста), а как максимум — какому-нибудь секретарю. Цепочка секретарь-менеджер-специалист и обратно может легко добавить неделю к реакции на правку. Все люди в цепочке как правило, занимаются еще и другими вещами, кроме вашего проекта, и не бросят все, чтобы отреагировать на ваше письмо. Каждый думает «Час ничего не решит.» А в итоге час умножается многократно и превращается в дни и недели.
3 причины, почему я никогда не обращусь в студию или большую компанию

(далее…)

Профессиональное командное поведение

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

Профессиональное командное поведение

Далее, короткая история из жизни и ИМХО о том, каким должно быть профессиональное поведение в команде.
(далее…)

Не паникуй (перевод главы книги «Passionate Programmer» by Chad Fowler)

Не паникуй (перевод главы книги «Passionate Programmer» by Chad Fowler)

Почему эта книга заслуживает перевода

Хочу поделиться своим мнением с хабрасообществом о книге «Passionate Programmer», перевод одной из глав которой представлен ниже. Книга вышла в 2009 году, но среди российских программистов она не очень широко известна, тем не менее многие, кто познакомился с ней, считают её очень достойной. Чад Фаулер (автор книги) выложился очень хорошо, чтобы передать читателям свой богатый опыт (на данный момент он CTO 6Wunderkinder, имеет более 20 лет стажа разработки и в виду своего большого опыта и круга интересов он желанный гость на Ruby- и IT-конференциях). Да, уже и не помню как нашёл эту книжку, но помню, что именно предисловие от Кента Бека (идейный вдохновитель Test Driven Development и Extreme Programming) послужило причиной прочитать её.

В этой книге нет описания конкретных технологий, алгоритмов и т.п., но есть просто куча советов, касательно того, с чем порой сталкивается любой разработчик: отсутствие мотивации, выбор приоритетов, психология программирования, отношения с руководством и коллегами; по большому счёту даётся масса наставлений, о том как сделать яркую карьеру программиста. Конечно, опытные разработчики могут найти некоторые его идеи достаточно очевидными, но для тех, кто только в самом начале своей карьеры, чтение данной книги, определённо, будет хорошим вложением времени. Большой плюс, что книга читается очень легко и, если вы достаточно хорошо владеете английским, её реально прочитать всего лишь за несколько дней. Просто интересно, почему наши издательства ещё не перевели её на русский язык?

После прочтения книги я заинтересовался Чадом. Нашёл его блог в сети. Как оказалось, он начал выкладывать в нём главы из своей книги (на данный момент опубликовано 2 главы из 53). Я спросил разрешения на перевод для хабра, он ответил, что это хорошая идея, но только сначала мне надо отправить ему письмо с тем, что конкретно я хочу переводить (видимо это пожелание было как-то связано с тем издательством, где была опубликована книга). После моего ответа неделю было молчание, я отправил повторное письмо — ответа снова не было. Потом я получил от него приглашение на Wunderlist (сервис, за который он отвечает на данный момент). В общем, я посчитал, что если явного запрета не было, а эти главы уже и так находятся в свободном доступе, и он ещё не совсем про меня забыл, то делать перевод можно. В общем, если перевод сообществу окажется полезным, я продолжу переводить другие главы. В тексте возможны ошибки (делал вычитку несколько раз, но всё же вдруг), поэтому заранее прошу прощения и прошу сообщать мне обо всех проблемах через личные сообщения.

(далее…)

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

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

Думаю, IT-примеры вам и так прекрасно знакомы, поэтому напомню пример из книги «Психология влияния»: психологи обзванивали медсестёр в больницах, а затем представлялись врачом и отдавали распоряжение ввести смертельную дозу вещества пациенту. Сестра знала, что делает, но в 95% случаев выполняла команду (её останавливали на входе в палату ассистенты психолога). При этом врач даже не был хоть как-то авторизован. Почему сестра так делала? Просто потому, что она привыкла слушаться авторитета.

Давайте ещё раз: в примере благодаря грамотной социальной инженерии 95% больниц оказались критически уязвимы. (далее…)