Приходя в новую компанию в роли ИТ директора, мы с вами, коллеги, невольно сталкиваемся с ошибками наших предшественников.

Конечно, в приступах перфекционизма, мы рвемся все сразу же исправить. Ну как же так можно работать? Это же неправильно! Так нельзя! И так далее…

И здесь многие из нас совершают большую ошибку.

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

Ведь как бы плохо не была построена система, какие бы жесткие ошибки не были допущены; — в любом случае система работала, система позволяла бизнес-персоналу зарабатывать деньги и еще куча доводов :)

Мы в «ИТ-ГРАД» постоянно обсуждаем технологии из сферы IaaS и пишем о других интересных находках наших специалистов. Сегодня мы решили разнообразить вашу ленту дайджестом для тех, кто хотел бы получить самые базовые сведения о виртуальной инфраструктуре и познакомиться с ее основными особенностями.


/ фото Robert CC

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

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



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

Пару недель назад в ИТ-отдел зашла сотрудница из опта и попросила доделать мелкую фичу к своему рабочему месту. Заявку вполне ожидаемо поставили в очередь.

Девушка немного обиделась и сказала:
— Это у вас сейчас несезон, и уже не успеваете. Посмотрю я на вас, что тогда к новому году будет!

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

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

Что может быть проще, чем разграничить права на папку в NTFS? Но эта простая задача может превратиться в настоящий кошмар, когда подобных папок сотни, если не тысячи, а изменение прав к одной папке «ломает» права на другие. Чтобы эффективно работать в подобных условиях, требуется определенная договоренность, или стандарт, который бы описывал, как решать подобные задачи. В данной статье мы как раз и рассмотрим один из вариантов подобного стандарта.

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

Теперь самое интересное: нужно каким-то образом вспомнить, к каким конкретно данным у этих товарищей был доступ, и что следует прикрыть в первую очередь.

Если с доступом к приложениям все очевидно и просто, то о файловых ресурсах такого не скажешь.

Акронис на прошлой неделе попросил меня рассказать про опыт на Хабре. После семинара я обещал выложить основные тезисы. Возможно, вы найдёте что-то полезное ниже.

Итак, Хабр, по моему мнению, это сейчас самая большая площадка Рунета для образованных людей. Сами по себе посты очень хорошо читаются, и это одна из главных сторон. Можно охватить порядка шести миллионов разных людей за пару лет.

При этом активных (голосующих) пользователей всего около 3 тысяч. Уровень знаний аудитории на входе в пост — в примерно 95% случаев низкий, в 5% — экспертный (разбиение оценочное). Проще говоря, есть люди, которые вообще не понимают, что вы хотите сказать (и их большинство), и есть те, кто разбирается в теме на голову лучше вас. Поэтому лучший пост — это тот, что проходит от ликбеза к хардкору. На площадке довольно высокий уровень агрессии (точнее, желания проверить материал на прочность). Ранее был экстремально высок. Средняя или низкая внимательность читателя (ранее была высокая).

Разумеется, это всё моё личное мнение, и можно поспорить. Сейчас постараюсь объяснить, почему я так считаю, и как это влияет на посты. Я основываюсь на опыте примерно 1500 постов за 6 лет, которые написал сам или помогал готовить.

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


^{Данные тут на конец августа, я их к другому семинару (в Хабре для владельцев блогов) готовил.}

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

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

Ого! Как много информации.

Добрый день, уважаемый Хабр! Поделюсь небольшим опытом в организации работы ИТ службы Банка. Статья не будет нагруженной описанием бюрократических составляющих, которые я выполнял для достижения цели и, надеюсь, мой опыт будет вам полезен.

Все началось с того, что в начале 2016 года меня пригласили работать в небольшой украинский Банк в качестве архитектора информационных систем (ИС). И одной из задач, которая перешла мне от прошлой команды, была задача организации работы ИТ службы в соответствии с сервисно-ресурсной модели. Да, задача безусловно не относится к архитектуре ИС, но послужила для меня своеобразным вызовом.

Факторы, повлиявшие на успех выполнения задачи:

• Поддержка руководства (уровень правления Банка);
• Желание модернизировать ИТ службу (как со стороны бизнес пользователей, так и со стороны работников ИТ службы);
• Личный опыт работы в данной модели управления на предыдущих местах работы.

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

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

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

Чтобы избавить себя от подобного рода проблем, я предлагаю рассмотреть различные аспекты тестирования баз данных. К которым можно отнести нагрузочное тестирование и проверку производительности SQL Server в целом при помощи юнит-тестов.

«Если у вас есть сомнения, авария это или нет — то это авария!»
(с) Мудрость предков

Большие сбои в онлайн-проектах происходят редко. А в больших проектах — ещё реже. Конечно, чем сложнее система, тем выше вероятность ошибки. Один час простоя крупных систем, особенно соцсетей, обходится недёшево, и потому в больших проектах прикладывается очень много усилий по предотвращению аварий и снижению негативного эффекта для пользователей. Но иногда то ли звёзды складываются в особенную комбинацию, то ли закон Мёрфи обретает реальную силу, и большие аварии всё же происходят. В истории Одноклассников крупнейший сбой произошёл 4 апреля 2013 года: в течение трёх дней проект был целиком или частично неработоспособен. О том, что же тогда произошло, по каким причинам и как мы с этим боролись, будет наш рассказ.

Сергей Рыжиков (1С-Битрикс)

Есть такое ругательное слово – бизнес-девелопмент. Мы часто можем его видеть на визитках у наших западных коллег. На самом деле, я толком даже не могу объяснить по-русски, что такое бизнес-девелопмент. Перед этой конференцией я попытался пошарить. В русском варианте вы не найдете нормального объяснения, что это такое. Есть западное определение.

Несколько лет назад в подмосковном офисе одной из компаний произошла разгерметизация газовой системы пожаротушения. Угроза для жизни и здоровья людей была более чем реальная. В результате ЧС 1 человек погиб, 13 с разной степенью отравления попали в больницу, 60 были эвакуированы. Подобные угрозы весьма актуальны – ведь точно такими же системами пожаротушения сегодня оборудованы десятки административных и офисных зданий в Москве, Санкт-Петербурге и других городах.

Возможна и другая ситуация: банк прерывает работу из-за угрозы взрыва. Тревожный сигнал может поступить от злоумышленника или хулигана, а может – от сотрудников банка, если они обнаружат в помещении подозрительный предмет или свёрток. Представляет ли он опасность, выяснится позже, однако действия по инструкции в такой ситуации строго обязательны.

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

При построении High Availability Configuration на базе оборудования RISC-платформ мы выбираем из весьма ограниченного набора кластерного ПО. В первую очередь это вендорские разработки – Oracle Solaris Cluster, PowerHA (IBM), Serviceguard (HP), а также Veritas Cluster Server. Последнее решение по факту является основным предлагаемым на данный момент вариантом построения кластерных конфигураций, причем для разных платформ – Oracle, IBM и т.д.

Однако мы решили не ограничиваться только этими разработками и поискать альтернативное кластерное решение для x86. Так был инициирован внутренний проект по тестированию кластерной конфигурации на базе ПО Pacemaker.

Давайте разберём уровни зрелости ИТ-процессов на примере управления инцидентами. Это всё то, что сыплется на ИТ-отдел в виде тикетов от пользователей, шефа, текущих задач и всего, что надо сделать. Забегая чуть вперёд, скажу, что в среднем по стране у крупного бизнеса с инцидентами довольно хорошо, в большинстве случаев это 4-й уровень. Ну просто потому, что работа со сбоями — это первое, по чему судят об ИТ-отделе.

Первый уровень — это когда:

• ИТ-отдел работает без распределения обязанностей и специализаций. Все отвечают за всё (точнее, ни за что), принцип выбора исполнителя — «Вася, ты свободен, ну, сделай им там».
• Ответственности нет: если Вася забыл, непонятно, кому писать, непонятно, как и что на что влияет, пользователи вообще не разбираются, кто и что делает. И иногда бьются в истерике.
• Документации нет.
• Автоматизации нет (либо есть на уровне списка задач в блокноте).
• Пользователи почти всё решают по личным знакомствам, обращаясь к тем, кто им уже один раз помог.

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

Учиться, учиться и еще раз учиться!
В.И.Ленин

Основная сложность в работе специалиста IT в том, что IT очень изменчивая область. Если вы не будете постоянно изучать что-то новое, вы рискуете остаться без работы. Закончим с прописными истинами, вы их и без меня знаете. Перейдём к практическим советам. Так как я уже много лет специализируюсь на «тёмной стороне силы» (IT менеджмент), и давно уже не программирую в коммерческих целях (только для души и редко — времени не хватает), то советы будут в основном для ИТ менеджеров (проект менеджеров, тимлидов, тим менеджеров и прочая и прочая братия, жирующая на шее трудяг программеров и сисадминов), но часть навыков пригодится любому IT специалисту.

Итак, что же надо изучать настоящему или будущему IT менеджеру, где изучать и сколько это стоит. Всё сугубое IMHO.

BPM «Как есть» и «как не есть»

Продолжаем размышлять «что такое BPM», это который «Business Process Management» и какие они бывают. Парадокс: про него столько уже десятилетиями понаписано — книжек, статей, дискуссий, но что это такое – сегодня так и остаётся загадкой, причем: чем больше пишут – тем более загадочнее становится.

Не помогают ни книжки из серии «Для чайников», ни заветы CBOK, ни магические квадраты от Гартнера (BPM: BPA, BPMS, iBPMS и т.п.), в которых, как и в черных квадратах Малевича (а у него только черных было несколько «разных» вариантов) – каждый норовит увидеть что-то великое и таинственное, ведомое только ему.

В главе предлагается вариант классификации BPM-подобных сущностей. В информационной войне с «алхимией 21 века» продолжаем развенчивать популярные мифы о Business Process Management, Enterprise Architecture (ЕА) и иже с ними. Делаем очередной шаг на пути становления BPM как обычной (повседневной, повсеместной, тривиальной) инженерной дисциплины: process technology, «процесс-техника».

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

Совершенно случайно, читая материалы по ISO 15288, я увидел схему «System interaction with Typical Enabling Systems» (оригинальный вид схемы намеренно приведен только в конце статьи), в которой достаточно наглядно изображены:

1. виды систем, задействованных в создании и обеспечении работы целевой системы
2. связи этих систем с целевой системой.

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

Наверняка многие из вас видели в интернете фотогалереи с заброшенными торговыми центрами, огромными и некогда роскошными. Впечатляющее зрелище, особенно для бизнесмена. Но первая мысль вовсе не о том, сколько денег, инвестированных в развитие, пропало. Она о том, почему это произошло. Да, есть фактор влияния структурных сдвигов экономики, есть и «вина» онлайн-торговли. Но главное — это неумение вовремя перестроиться, адаптироваться, изменить бизнес-модель. Причём не отказываясь от существующей, а встраивая её в новые условия.
Та же история может случиться с проектом внедрения CRM: система простаивает, компания меняет вендора, выбирает более дорогую систему, которая снова простаивает… Замкнутый круг. А между тем, причины неудачи довольно линейны — и в ваших руках сделать внедрение CRM успешным. Делимся опытом, как.

15 июня Государственная Дума РФ приняла в третьем окончательном чтении так называемый «Закон о налоге на Гугл». Законопроект получил такое название в связи с введением НДС на «оказание услуги электронным способом» иностранными ИТ-компаниями. С полным текстом законопроекта можно ознакомиться здесь.

Чем грозят налоговые поправки российским посредникам и потребителям?