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

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

В центре цифровой трансформации находятся центры обработки данных (ЦОД). Текущие тенденции развития ЦОДов показывают, что потребность в пропускной способности их сетей будет ежегодно увеличиваться на 25-35%. Архитектура сети ЦОДа должна гарантировать обработку больших объемов трафика и, что не менее важно, масштабирование серверных, сетевых ресурсов и ресурсов систем хранения с наименьшим объемом отключений и переконфигураций.

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

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

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

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

От переводчика: любопытная статья Стюарта Рэйнса с предложением, как ИТ повысить свою ценность в рамках компании, перейдя от управления инцидентами в ИТ к управлению инцидентами в бизнес процессах компании.

Идея не нова и известна, как Enterpeise Service Management. Вряд ли его можно и стоит применять повсеместно, но если у руководства компании есть вера и доверие к ИТ, а также персонал и процессы ИТ обладают соответственно высокими уровнями сервисной культуры и зрелости. Тем не менее, как саму идею стоит знать и понимать, также она вполне подходит, как цель, к которой стоит стремиться.

Ссылка на оригинал
Опубликована 15.01.2018.
Сложность: начальный уровень (идеология)

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

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

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

История началась с того, что нам понадобился доступ к HR-системе для чат-бота. Чтобы последний мог искать контакты сотрудников по запросу вроде: «Найди того, кто может починить пиканиску». В корпоративной инфраструктуре это выглядит так: мы идём в отдел автоматизации и говорим, что нам нужны данные из HRMS. И получаем закономерный ответ:
— Пишите ТЗ, предоставим API и сервер интеграции через 6 месяцев.
— Парни, вы чего? Нам бы побыстрее!
— Тогда пишите ТЗ и письмо руководителю, сможем СРОЧНО уложиться за 3 месяца.

А нам надо было за 3 дня. Поэтому мы пошли другим путём: попросили кадровиков завести нам бота в список сотрудников и дать ему доступ к системе. Дальше он уже делал то, что на его месте мог бы делать человек.

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

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

Предполагается, что студент должен страдать самостоятельно освоить ноты, путем многократного повторения. И вообще, если «ниасилил», значит у тебя нет Таланта — иди мести двор.

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

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

Дисклеймер

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

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

Введение

Чтобы читателям был понятен контекст, мы решили начать с бэкграунда. Статья написана аналитиком информационной безопасности (мной) и специалистом по тестированию на проникновение (моим коллегой InfiniteSuns ).

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

Далее в ходе обсуждения выяснилось, что до этого под названием «пентест» заказчику продавали сканирование внутренней сети при помощи «nmap» с параметром «--script vuln». Естественно, в очередной раз заказчик ожидал от пентестеров подобного поведения и искренне удивился, когда они начали захватывать его контроллер домена.

Рис. 1.

О чем исследование

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

Disclaimer
Статья не содержит конфиденциальной информации. Все использованные материалы публично доступны в Интернете, в том числе на сайте Банка России.

В этой статье с картинками Кнопка расскажет о том как развернуть свой собственный фреш с блэкджеком PostgreSQL и Linux. Надеемся, что она поможет тем, кто пытается установить у себя 1С Fresh и немного потонул в объемах официальной документации. При развертывании мы будем максимально использовать свободное ПО.

С 1 января ФНС перестанет обновлять адресный справочник КЛАДР. Он официально устареет, останется один ФИАС. Но многие промышленные системы до сих пор работают с КЛАДР. Поставщики не собираются их обновлять, а переделывать своими руками бизнесу выходит долго и дорого.

Мы послушали клиентов и придумали решение: взять ФИАС, который живее всех живых, и написать перекодировщик в КЛАДР.

Со стороны задача кажется легкой. Нам так и говорили: «То есть вы просто берете ФИАС и переделываете в КЛАДР?». На деле никакого «просто» нет. У справочников совсем разные структуры и непонятно, как из подкачанного ФИАС раскидать данные в неказистый КЛАДР. При этом общей документации для справочников нет.

Это было веселье, которым мы сейчас щедро поделимся.

Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!

Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.

Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.

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

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

Эта статья является попыткой обобщить имеющийся опыт, а также на неё я собираюсь ссылаться, когда меня будут в дальнейшем спрашивать, как должен выглядеть SLA. Работая в индустрии не первый десяток лет, я к своему удивлению регулярно сталкиваюсь с серьёзным непониманием основ, на которых строится SLA. Наверное, потому что документ довольно экзотический. После прочтения данного текста, я надеюсь, у вдумчивого читателя точечки над ё должны встать на свои места. Целевая аудитория — те, кто пишет SLA, и им сочувствующие.

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

Так что же такое эскалация, кому и зачем она нужна? Сейчас расскажу своё понимание, после которого Вы, как я надеюсь, полюбите эскалацию также, как и я. Держитесь крепче за стул.

 
Центр интернет-безопасности (CIS) является некоммерческой организацией, которая разрабатывает собственные контрольные показатели и рекомендации, которые позволяют организациям совершенствовать свои программы обеспечения безопасности и соответствия требованиям. Эта инициатива направлена ​​на создание базовых уровней конфигурации безопасности систем, которые обычно встречаются во всех организациях. В этой статье я продолжу публикацию лучших практик и советов по организации информационной безопасности.

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

Далее привожу все найденные мной факторы, которые привели меня к столь неприятному положению дел.

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

В данной статье мы расскажем, как эксплуатировать ShellShock на клиенте DHCP и получить на нем полноценный reverse или bind shell. Интернет пестрит статьями, повествующими о возможностях эксплуатации shellshock на DHCP-клиентах. Есть даже статьи о том, как получить reverse shell на DHCP-клиенте. Однако, стабильно и повсеместно работающего инструмента для получения shell мы еще не встречали. Те, кто в теме, возможно, нового здесь не увидят, но не исключено, что вам будет интересно узнать, как нам удалось автоматизировать получение reverse и bind shell в условиях фильтрации и экранирования символов на стороне DHCP-клиента. Кроме того, мы расскажем и о том, чем вообще может быть интересен протокол DHCP.

При слове «инвентаризация» обычный человек вспоминает ситуацию, когда придя в магазин, видишь табличку на закрытой двери и думаешь, что тебе придётся пройти ещё несколько домов, а в худшем случае и кварталов, чтобы купить необходимое. Необычный человек, работающий с Microsoft System Center Configuration Manager, при упоминании этого слова, представляет кипу проблем, связанных с достоверностью получаемых результатов. Про их решение мы и поговорим под катом.