• Почему финансовые директора так хотят перевести капитальные расходы на ИТ в операционные



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

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

      Как написал kaichou в комментарии: «а потом, пару лет спустя, выясняется, что на облако в год тратится столько денег, сколько стоил весь собственный серверный парк». И эта ситуация вполне нормальна для финдиректора. Сейчас постараюсь объяснить, как он в такой ситуации мыслит.
      Читать дальше →
    • Реакция на аварию: растянутый кластер против DR-площадки



        У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами). Они имеют несколько точек сохранения снэпшотов.

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

        У методов есть плюсы и минусы, сейчас про них расскажу.
        Читать дальше →
      • Обзор ЦОД IXcellerate (самый большой машзал в РФ)



          Самое главное — тут после машзала подают горячие влажные салфетки, как в японских ресторанах. Это не имеет никакого отношения к технической части, но по-человечески приятно.

          А это гитара с автографом Пола Маккартни, и да, она у них висит на входе в машзал:



          У этого ЦОДа есть определённое настроение.

          Выглядит всё это как огромный ангар в промзоне около метро «Отрадное». Высота ангара — 14 метров, внутри построен ЦОД высотой 9 метров. Оставшееся пространство играет роль теплоизолятора, что сказывается на местных особенностях охлаждения. Здание выбиралось так, чтобы не выходило на дорогу краями (по протоколам сертификации нельзя получить высокие уровни, если в машзал можно попасть на грузовике, протаранив стену, — видимо, были случаи), имело два разных маршрута заезда и было относительно недалеко от метро. Там же рядом открыли станцию МЦК, но дорога идёт по таким весёлым местам….
          Читать дальше →
        • Мы хотим заменить девопсов скриптом (на самом деле нет): разработчики, нужно ваше мнение


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

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


              Самая большая голова Ленина в мире. Площадь Советов в Улан-Удэ

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

              Всё было не зря.

              Такие истории очень хорошо рассказывать через пару лет в курилке, но не встречать на проектах.
              Читать дальше →
            • В информационных технологиях есть своя особая атмосфера

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



                Этим наш дорогой коллега решал одну ИТ-проблему. Дело в том, что мы оснащали серверный узел в здании (маленький ЦОД на 20 стоек) серверами. Во время работ фальшпол начал гнуться — медленно так, с треском и вообще как в фильмах ужасов. Это оттого, что рядом поставили блоки ИБП, по 20 килограмм на юнит. Не проверив допуски.

                Чтобы не было эффекта домино, Женя принял решение повытаскивать батарейные блоки. Это не особо помогло. Но с помощью бордюрного камня удалось чуть замедлить процесс. Ещё через час приехала команда подрядчиков, строивших этот ЦОД, с примерно 30 домкратами из автомагазина для ремонта. Три недели переделывали, только потом мы смогли продолжить.
                В общении с иностранными коллегами мы описываем это как surprisingly amazing. Со своими есть более точный термин — «клоунада».
                Читать дальше →
              • Что надо забыть админу при переходе на облако — и что подучить

                  Вот один из самых страшных экранов для тех, кто переезжает с физического железа:



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

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

                  Потому что с момента начала виртуализации надо забыть половину того, что ты знаешь, и начать ботать сеть.

                  Если вы читали на ночь Олифера «Компьютерные сети» или книгу с таким же названием Таненбаума, то проблем не будет почти точно. Это когда-то было классикой админов в свитерах, а теперь стало классикой админов в галстуках.
                  Читать дальше →
                • Дверь, которая с нами здоровается по именам и открывает только сотрудникам отдела


                    У нас была пара дней промежутка между большими проектами, и мы решили поиздеваться над дверью руководителя подразделения. Just for fun. Потому что дроны нас в лицо уже узнают — чем дверь-то хуже?

                    На момент старта IT-проекта у нас уже была накладная панель, напечатанная на 3D-принтере. За два дня из железа, готовых библиотек и какой-то матери мы сделали прототип устройства, которое учитывает сотрудников или позволяет проверять, что человек прошёл через турникет именно по своему пропуску.

                    Никаких денег. Мы использовали только опенсорс.

                    Вы можете повторить это минут за 15–20 с нашим скриптом.
                    Читать дальше →
                  • OpenStack: вся правда о «королевском» релизе

                      Воланд у М. Булгакова говорил, что «кирпич ни с того ни с сего никому и никогда на голову не свалится». Может, и так, но, когда два с половиной года назад меня спросили, хочу ли я познать OpenStack, это был тот самый хорошо завуалированный кирпич (а на старте даже не кирпич, а гранитная плита). Именно 2016 год стал для меня так называемой «точкой невозврата», положив начало стремительному освоению концепций открытого мира и в значительной степени повлияв на менталитет, – превратив мою дальнейшую жизнь в праздник. «Праздник», который всегда со мной.


                      Читать дальше →
                    • Эффективность потребления вычислительных ресурсов


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

                        С вычислительными ресурсами примерно похожая история. Редко кто использует их полностью эффективно. Давайте поговорим об эксплуатации и немного о следующем поколении программирования под такие среды, где важно очень гибко разделять ресурсы.
                        Читать дальше →
                        • +18
                        • 4,4k
                        • 8
                      • Закупка железа против облака: как правильно считать



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

                          Совокупная стоимость владения физическим оборудованием — вещь сложная, особенно если вспомнить про меняющуюся стоимость денег, покупки в кредит и другие параметры. Давайте я покажу, по какой методике мы считаем и в каких случаях физическое железо лучше.
                          Читать дальше →
                        • Управление рисками на ИТ-проектах: что поменялось за последние годы

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

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

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



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


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

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

                              Читать дальше →
                            • Как мы организовали хранилище данных дешевле Amazon Simple Storage Service на 35%



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

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

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

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

                                Стояла задача сделать его не просто работающим отовсюду, но и дешёвым.
                                Читать дальше →
                              • Кому НЕ надо переезжать в облако и почему



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

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

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

                                  Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.
                                  Читать дальше →
                                • Срочный переезд с Amazon Web Services — истории двух клиентов



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

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

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

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



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

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

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

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

                                    Задержки продолжили копиться.
                                    Читать дальше →
                                  • Как мы побеждали бардак с железом и становились бюрократами с нуля


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

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

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

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

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



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

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

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


                                          Источник


                                          "Талант сам по себе бесцветен и приобретает окраску только в применении".
                                          М.Е. Салтыков-Щедрин


                                          Кадры действительно решают всё. А в условиях развития цифровой экономики кадры нужны особенные. И для взращивания таких кадров надо создать соответствующие условия.


                                          Несмотря на все проблемы ИТ-отрасль остается одной из самых эффективных в экономике России. Согласно оценке Минкомсвязи, один сотрудник в данной сфере создает продукцию и услуги на сумму в среднем более 2 млн. рублей в год. Но только 15-20% выпускников готовы к немедленному трудоустройству и эффективной работе в сфере ИТ, по оценкам экспертов Института развития Интернета (ИРИ) «Взаимодействие ИТ бизнеса и ВУЗов». Что же пошло не так в вузовском образовании?

                                          Читать дальше →

                                        Самое читаемое