Рубрика «Блог компании ТЕХНОСЕРВ» - 3

в 7:08, , рубрики: Блог компании ТЕХНОСЕРВ, Карьера в IT-индустрии, ПМ, риски, управление персоналом, управление проектами, Управление проектом, управление разработкой

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

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

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

в 7:02, , рубрики: pcf, pivotal, Блог компании ТЕХНОСЕРВ, ит-инфраструктура, облака, облачная инфраструктура, Облачные вычисления, облачные сервисы, Техносерв
Как развернуть инфраструктуру для Pivotal СF, или Рецепт слоеного пирога в картинках - 1

Год назад в центр компетенций по системам управления ИТ и мониторинга «прилетела» задача: развернуть продукт Pivotal Cloud Foundry (являющийся, фактически, эталонным образцом модели PaaS). В двух словах, Pivotal Cloud Foundry (PCF) – это готовое коммерческое решение для предприятий, которые:

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

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

Читать полностью »

в 7:06, , рубрики: amazon, AWS, s3, Блог компании ТЕХНОСЕРВ, облако, облачное хранение данных, облачное хранилище, облачные сервисы, СХД, хранение данных

Как мы организовали хранилище данных дешевле Amazon Simple Storage Service на 35% - 1

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

На втором этапе мы стали использовать объектное хранение, то есть хранение без иерархии каталогов. Все данные лежат на одном уровне, и каждый файл может быть доступен по своему ключу. Метаданные хранятся рядом с файлом. Для доступа используются простые команды уровня PUT — GET — MODIFY, есть возможность обратиться к каждому файлу по собственному URI, обеспечены лёгкость управления правами и лёгкость размещения самых разных данных и доступа к ним.

Минус данных решений — невозможность обращения к части (сегменту) файла, поэтому для приложений вроде баз данных такие хранилища не используются. Оптимальное применение — сложить туда картинки веб-сайта, файловую помойку, архивы или бэкап данных. На базе объектного хранилища мы построили свой S3 — систему хранения не очень часто изменяемых данных. С прямой совместимостью с Amazon S3.

А ещё классические протоколы доступа, использующиеся внутри компаний для файлового доступа (CIFS или NFS), не предназначены для обмена большими данными через сеть Интернет. Это ещё одна из причин, почему и зачем мы создали своё объектное хранилище.

Стояла задача сделать его не просто работающим отовсюду, но и дешёвым.
Читать полностью »

в 7:04, , рубрики: Блог компании ТЕХНОСЕРВ, виртуализация, инфраструктура, облако, переезд, управление проектами

Кому НЕ надо переезжать в облако и почему - 1

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

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

Более сложная ситуация — это когда железо кто-то купил 20 лет назад (я сейчас не шучу), а оно ещё нужно. Точнее, нужно что-то, совместимое с ним. Я видел софт, который писался 15 лет назад, 20 лет назад и даже 25 лет назад. Тот, кто его писал, давно уже умер или не работает. А это, например, реестр в госструктуре на мейнфрейме или код банка, привязанный к микроинструкциям конкретной линейки процессоров или специфическим функциям ОС. Исходников нет. Документация только для эксплуатации. Если повезёт.

Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.
Читать полностью »

в 11:30, , рубрики: AWS, Блог компании ТЕХНОСЕРВ, виртуализация, миграция, облако

Срочный переезд с Amazon Web Services — истории двух клиентов - 1

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

19 апреля они заметили блокировку одного из IP-адресов своего публичного сервиса частью провайдеров на территории РФ. 20 апреля ситуация усугубилась — вся подсеть стала недоступной. Это уронило тестовую среду, один из резервных каналов, частично нарушило работу почтовых серверов. Проблему удалось решить заменой IP-адресов, проксированием трафика через другие дата-центры.

Когда стало понятно, что всё это всерьёз и надолго (точнее, когда возник такой риск), один наш заказчик, компания Теко — международная процессинговая компания, решил развернуть инстанс в нашем облаке. Их CIO была важна большая федеративность сервиса, большее присутствие на территории РФ. Цитата:

«Облако в РФ даёт больше гарантий клиентам, что сервис не будет заблокирован РКН. Скорость, с которой нам предоставили ресурсы, была очень важна. Происходило всё достаточно быстро: первым делом мы добавили GEO dns для доступности сервиса на территории РФ, начали проксирование трафика через незаблокированные ДЦ. Медленная часть — федерация для БД».
Читать полностью »

в 7:00, , рубрики: Блог компании ТЕХНОСЕРВ, встречи, Карьера в IT-индустрии, коммуникации, письма, ПМ, разработка, управление персоналом, управление проектами, Управление проектом, управление разработкой

Управляем большим длинным проектом: почему важно разговаривать словами - 1

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

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

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

Он собрал совещание, но на нём молчал. И все молчали. Точнее, докладывали статусы и поднимали проблемы. Результат совещания — он написал ещё одно длинное письмо с требованиями и фиксацией статусов с косяками.

Задержки продолжили копиться.
Читать полностью »

в 7:15, , рубрики: itsm, Анализ и проектирование систем, Блог компании ТЕХНОСЕРВ, инфраструктура, порядок, системное администрирование, управление изменениями, управление проектами

Как мы побеждали бардак с железом и становились бюрократами с нуля - 1
Разница между документацией и базой знаний: документация говорит, что это устройство охлаждает воздух до +18 градусов по Цельсию, а база знаний подсказывает, что есть редкий баг, когда два датчика сразу показывают -51 тысячу градусов и устройство начинает лихорадочно греть воздух для серверов.

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

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

Но начали мы с простого. Вопросы были такими: Кто обновляет прошивку сервера? Кто отвечает за результат? Как это делается? Кого надо предупредить? Как писать план отката и что делать, если сервер упадёт? Кто-то записал все телефоны нужные заранее хотя бы?

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

в 8:20, , рубрики: Datapro, Блог компании ТЕХНОСЕРВ, виртуализация, дата-центр, облако, Серверное администрирование, Техносерв, физическая защита, цод

Дата-центр с интересной физической защитой - 1

Мы используем для своего облака дата-центр DataPro. Да, интегратор «Техносерв» строил дата-центры и серверные узлы, да, мы умеем это делать, да, у нас есть нужные инженеры в штате, но мы предпочитаем отдавать именно размещение на аутсорс. Почему? Потому что дата-центр в виде IaaS — это, очень упрощая, как холодильник или склад. Ничего романтического — просто место, куда надо поставить сервер. Охлаждение, питание, регламенты и всё остальное — это очень много компетенций, которые не нужны в облаке. Хранение чужих серверов включёнными — это отдельный бизнес.

Почему мы выбрали DataPro? Потому что они параноики в классическом военном смысле. Например, никогда не зависят от одного вендора. Или вот давайте просто дойдём до нашего сервера и посмотрим, сколько раз нас по дороге остановят.

Сначала нас остановит забор с набором датчиков. Если его потрясти в любом месте или попробовать на него залезть, то сработает датчик вибрации, и сразу выдвинется патруль охраны.
Читать полностью »

в 5:59, , рубрики: Блог компании ТЕХНОСЕРВ, дистрибуция софта, инвентаризация, инвентаризация ОС, Серверное администрирование, Системы управления версиями, управление лицензиями, управление сервером

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

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

image
Читать полностью »

в 7:22, , рубрики: ethernet, leaf, Spine, архитектор, архитектура, Блог компании ТЕХНОСЕРВ, виртуализация, Серверное администрирование, сетевой архитектор, Сетевые технологии, сеть

Я сетевой архитектор, и меня это беспокоит - 1
Порты на коммутаторе в нашем нашем дата-центре

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

Ну и да. А ещё есть текущие проблемы стандартов сетей (отставших от реальных требований на лет десять). Чаще всего это означает выдумывание хитрых велосипедов вместо того, чтобы применять очевидные, казалось бы, решения. Но велосипеды есть везде, конечно.
Читать полностью »

1...234...5
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js