Русский
Русский
English
Статистика
Реклама

Телеком

Основные тренды развития телекоммуникаций в эпоху всем надоевшей пандемии

29.10.2020 14:07:14 | Автор: admin
image

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

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

Затраты компаний на оборудование для облачных сервисов растут


По данным экспертов Idc, выручка производителей сетевого оборудования, включая серверы, СХД, коммутаторы, постепенно растет. Объясняется это просто бизнесу и государственным учреждениям необходимо быстро развивать телекоммуникации, чтобы выдержать растущую нагрузку на сети. Соответственно, растут затраты у одних компаний и прибыли у других.

Так, увеличение выручки от продаж оборудования для облачной инфраструктуры по сравнению с прошлым годом составило 34,4%. А вот аналогичный показатель для оборудования, которое не связано с IT-инфраструктурой, снизился на 8,7%% по сравнению с прошлым годом.

Что касается общедоступных облачных сервисов, то здесь расходы за год выросли на 47,8%, достигнув показателя в $14,1 млрд. Аналитики утверждают, что в этом году расходы этого типа впервые превысили расходы на традиционную IT-инфраструктуру. Ну а поскольку пандемия развивается, то рост облаков будет продолжаться. По мнению экспертов, к концу года расходы бизнеса на этот сегмент составят примерно 54%.

Основные драйверы роста


Тренды, о которых идет речь, были хорошо заметны уже весной рынок очень активно реагирует на изменения во всех сферах работы и жизни. Стало популярным дистанционное образование, развивается телемедицина, увеличивается количество развлекательных сервисах. Это не могло не повлиять на увеличение закупок сетевого оборудования и всего, что связано с облаками. По мнению аналитиков, к концу этого года расходы бизнеса и государственных организаций на платформы для облачной инфраструктуры вырастут на 50,9%, достигнув объема в $37,7 млрд. Активнее всего растет рынок корпоративных СХД и коммутаторов Ethernet.

Эти тренды проявили себя не в каком-то одном регионе, а практически во всех странах, включая Европу, Китай и США. В последних двух регионах годовой показатель роста составил 60,5% и 36,9%. При этом публичные облака развиваются гораздо быстрее, чем частные. К концу этого года выручка от них повысится на 15% до $52,4 млрд.

Если говорить в общем, то к 2024 году расходы на облачную IT-инфраструктуру увеличатся до отметки в $109,3 млрд. Это около 63,6% от общего объема расходов на IT-инфраструктуру. Расходы на частную облачную инфраструктуру увеличатся в среднем на 9,3%.

Увеличился спрос и на гибридные решения. Дело в том, что у большинства компаний, как небольших, так и крупных, разнородная IT-инфраструктуры. Поэтому для оптимизации компании выбирают многокомпонентные среды, используют выделенные инфраструктуры в коммерческих ЦОДах.

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

image

А что в России?


Не удивительно, что в РФ рынок облачных услуг тоже растет он увеличился на 24,8% в этом году, превысив ожидания аналитиков. Понятно, что большинство прогнозов составлялись в прошлом году, так что они несколько отстают от реальных показателей. В РФ, как и во всем мире, превалирует рынок публичных облаков его доля составляет 85% на рынке облачных решений. Львиная доля этого рынка принадлежит корпорации Microsoft.

В 2019 году выручка 10 крупнейших отечественных поставщиков SAAS (Software-as-a-Service) увеличилась на 48% по сравнению с 2018 годом. В абсолютном значении объем рынка увеличился для 48 млрд рублей. Что касается рынка IaaS в РФ, то объем его был в два раза меньше. Выручка топ-10 компаний из РФ составила около 24 млрд роста. Если брать топ-100 компаний, то общий объем их выручки в РФ по итогам прошлого года увеличился на 22%.

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

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

Фиксированная связь с ней все хорошо?


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

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

Но, к сожалению, у многих провайдеров и операторов падает выручка. Так, из-за того, что многие сервисы предоставлялись бесплатно, падение составило 5-10%. Правда, в условиях второй волны карантина возможно начало бурного роста, который перекроет падение выручки.

С другой стороны, нельзя забывать об инициативе правительства РФ в плане предоставления бесплатного доступа к социально значимым ресурсам. Операторы, хотя и без особого энтузиазма, стали искать решения, которое помогли бы выполнить эту инициативу.

Что дальше?


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

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

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

Выход здесь один закупать новое оборудование, строить сети и прокладывать кабели. Одними административными мерами здесь не поможешь.

В свете пандемии и удалёнки, присмотритесь к централизованной системе управления сеть Zyxel Nebula. Это экосистема аппаратных и программных компонентов, которая поможет не только развернуть сеть УДАЛЕННО, но и управлять и масштабировать. Прицепить точку доступа на потолок в филиале и воткнуть в нее RJ-45 может любой дядя Вася, а администратор, удаленно подключается к точке, настраивает ее и контролирует параметры ее работы. То же и с коммутаторами и межсетевыми экранами.



Задать вопрос специалистам, запросить оборудование на тестирование и вообще, удобно в нашем телеграме t.me/zyxelru.

Добро пожаловать!
Подробнее..

Опыт построения сети DWDM

13.02.2021 20:21:59 | Автор: admin

Как известно, работа большинства инженеров-связистов/ сетевиков/ IT-шников остается в тени до момента, когда что-то пойдет не так. Неосведомленные люди и не понимают, чего все эти инженеры сидят и с умным видом смотрят в компьютер, читают и пишут какую-то абракадабру на непонятных языках. А вот когда, что-то пошло не так, все (и особенно руководство) сразу начинают вспоминать названия всех краснокнижных животных.

Итак, вот чем занимаются все эти инженеры и какие задачи им приходится решать, на примере реализации одного из довольно непростых проектов развертывание DWDM-сети.

Постановка задачи

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

Связисты знают, что такое волновое уплотнение каналов, т.е. когда несколько каналов передаются внутри одного волокна путем разнесения частот/длин волн (кому как нравится). Кто не знаком, можно подчитать тут.

Dense Wavelength Division Multiplexing (DWDM)Dense Wavelength Division Multiplexing (DWDM)

К слову сказать, DWDM не часто встретишь у корпоративных клиентов, разве что у очень крупных. В основном DWDM встречается на операторских сетях.

Сбор исходных данных

Все этапы проекта важны, а о важности этого этапа даже и не стоит говорить, это очевидно!

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

При выборе остановились на решении Huawei OptiX OSN 8800.

Проектирование

Стоит сказать, что рассчитать серьезную систему DWDM без специальных знаний нельзя, очень много нюансов, это не какая-то коробка, которую можно просто принести и включить (см. рис., как примерно выглядит типовой узел DWDM)! Лазеры, транспондеры, окна прозрачности, мультиплексоры/демультиплексоры, дисперия, поляризация Does that all make sense?

Пример типового узла DWDMПример типового узла DWDM

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

Пример расчета узлов DWDMПример расчета узлов DWDM

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

Реализация

Поставка оборудования DWDM дело штучное, под заказ, по сути, оборудование со всей начинкой производится под конкретный проект. Здесь тоже оказалось все в порядке Huawei произвел и поставил оборудование в срок!

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

И вот, случился сложный момент та самая оптическая трасса с рамановскими усилителями. Если кратко, на дилетантском уровне, рамановский усилитель светит навстречу принимаемому сигналу, чтобы его вытянуть! Участок с рамановскими усилителями требует наличия оптики практически сверхидеального качества, не только без стыков через оптические кроссы, но и с минимальными потерями и отражениями при сварке оптического кабеля (см. требования ниже).

Требования к оптической трассе для работы рамановских усилителейТребования к оптической трассе для работы рамановских усилителей

Если рядом с рамановским усилителем случится отражение сигнала,- приемник может просто сгореть!

А где вы видели 150+ км. оптического кабеля без стыков и сварок? И вот тут начались игры с доведением оптического кабеля до нужных характеристик. Практически по всей длине 150+ километровой трассы были заменены оптические разъемы UPC на APС (про разъем E2000 кто-нибудь слышал? а они есть), потребовалось даже заменить небольшой оптический участок на последней миле.

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

Приемосдаточные испытания

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

Так, самую большую опасность представлял сценарий с обрывом только Rx или Тх, и несмотря на наличие специализированных протоколов (LPT, ALS) для автоматического восстановления сервиса, время схождения превышало 150мс, что означало, что на это время наблюдалась частичная потеря трафика и потребовалось срочно найти дополнительные механизмы, чтобы оперативно дать понять сетевому оборудованию, стоящему за DWDM, о необходимости использования альтернативного пути.

Решение было найдено - использовать комбинацию технологий Ether-Channel и L2 BFD на коммутаторах Huawei. Минимальные таймеры BFD позволяли детектировать проблему наличия односторонней передачи еще до того, как оборудование DWDM исправит ситуацию, используя свои собственные механизмы, в результате СПД практически не замечала проблем на сети DWDM. Протоколы и таблицы маршрутизации не разъезжались, соседства не терялись, все были довольны!

Миграция

Ну, и напоследок миграция всех существующих сервисов работающей крупной финансовой организации на новую DWDM сеть.

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

Сухой остаток

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

Справедливости ради хотел бы отметить, что в течение всего этого проекта была поддержка со стороны вендора! За время проекта мы открыли порядка десяти, а может и поболее кейсов и всегда получали ответы на интересующие вопросы!

Многие ругают TAC'и вендоров. Опыт работы с TAC Huawei на этом конкретном проекте сугубо положительный! В подавляющем большинстве кейсов мы получали оперативные, грамотные ответы, может не всегда после первой итерации, но получали. Бывало, требовалось подключение R&D из Китая, но результат был всегда! ( Ну, или может дело в том, что вместе с оборудованием и поддержка была закуплена?).

Поэтому благодарности не только команде BCC, но и команде Huawei!

P.S.: Да, несмотря на всю правдивость истории, все совпадения случайны.

P.P.S.: Описание проекта также доступно здесь.

Подробнее..

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

23.10.2020 20:07:00 | Автор: admin


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

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

Мы выпускаем новые версии нашего биллингового софта по графику, 6 раз в год. Даты отгрузок релизов известны заранее. На момент написания этой статьи у нас уже есть запланированные даты релизов на весь следующий год.

Такая специфика связана с гонкой сотовых операторов за time-to-market. Главный принцип: абонент должен регулярно получать новые фичи биллинга. Платежи через смартфон, сохранение номера при смене оператора, возможность продавать неиспользованный трафик обновления могут быть разными.

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

У нас на стороне разработки биллинга в релизе участвует порядка 70 человек. Это 5-6 команд, каждая со своей специализацией: аналитика, разработка (несколько команд), функциональное тестирование, интеграционное тестирование.

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

Зона дискомфорта


На момент начала описываемой истории, два года назад, мы имели следующую картину:

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

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

Мы решили изменить этот расклад: поставили цель ноль ошибок на бизнес-приёмке на новой функциональности.

Через год мы смогли снизить число ошибок до 10-15, к середине 2020 до 2-3. И вот в сентябре нам удалось достичь целевого нулевого показателя.

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

Точки роста


Главный инструмент интеграционного тестирования тестовый стенд. Там происходит эмуляция деятельности абонента.

Общие стенды


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

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

Различия не критические, но всё-таки были. Это приводило к тому, что при тестировании на стороне заказчика могли появиться ошибки, которых не было у нас.

Что мы сделали: договорились, что схемы данных, на которых происходит тестирование, будут одинаковые, и в целом у нас будет общий стенд.

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

Проверка настроек перед тестированием


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

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

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

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

Что мы сделали: ввели процедуру проверки нами настроек на стороне заказчика перед началом тестирования на стендах оператора.

Процедура такая: заказчик выбирает кейсы, которые мы показываем на настроенном стенде. Запускаем тесты. Если ошибки есть, мы их оперативно исправляем; если нет тест считается пройденным.

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

Дополнительные коммуникации вокруг документации


Проверка настроек перед тестированием вдобавок к описанию этих настроек в мануалах это один пример дополнительных коммуникаций вокруг документации. Были и другие.

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

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

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

Всё это позволило лучше информировать заказчика о новой функциональности и через это уменьшить число ошибок на интеграционных тестах.

Экспертиза по работе со сторонними системами


Для разработки биллинга нам нужно уметь вести учёт трафика. Для этого существуют отдельные PCRF-системы. Учёт звонков происходит в одной базе, СМС там же, а трафика в другой базе; и есть специальное ПО, которое это всё синхронизирует.

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

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

Что мы сделали: завели отдельную внутреннюю базу знаний по PCRF. Каждый инцидент, каждый вариант настройки, каждый инсайт всё записывалось и шарилось в команде.

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

Больше стендов


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

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

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

Что мы сделали: завели отдельный стенд для каждого тестировщика.

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

Виртуализация


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

Что мы сделали: задействовали виртуализацию.

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

Планирование


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

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

Саппорт и релиз параллельно


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

График выпуска релизов при этом не сдвигался. В итоге в то время, когда уже пора было заняться следующим релизом, мы могли всё ещё продолжать заниматься предыдущим.

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

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

Хронологически это была одна из первых точек роста, которую мы сформулировали на постмортеме. И тут мой рассказ подходит к части про главный инструмент.

Главный инструмент


Улучшение, которое помогло нам больше всего честные постмортемы.

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

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

За два года движения к цели в ноль ошибок у нас сложился ряд принципов, как мы проводим постмортемы.

  • Собрать полную картину

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

  • Не хвататься за всё сразу

Ок, по итогам постмортема мы придумали 30 точек роста. Сколько брать в работу? Может, у нас получится решить все до следующего раза? Для нас лучше всего сработал формат выбрать 2-3. При таком раскладе есть фокус, и усилия людей в команде не распыляются. Лучше сделать меньше, но полностью, чем много, но не довести до ума.

  • Не мудрить с форматом

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

  • Брать в работу

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

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

Самый главный инструмент


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

Самый главный инструмент вовлечение команды.

У вовлечения есть инструментальная сторона. Например:

  • если работаем сверхурочно, то начальник рядом с командой, помогает руками;
  • если подбадривать команду трекингом прогресса, то найти наглядные метрики (для числа ошибок несложно).

И дальше в том же духе.

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

Люди самое главное.



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

Нам с командой ещё многое предстоит сделать в борьбе за качество релизов и оптимизацию time-to-market. Сделать регулярно воспроизводимым результат с нулем ошибок на интеграционных тестах, автоматизировать регресс.

Как достичь этих целей нам ещё только предстоит выяснить. Но что мы точно знаем уже сейчас: мы обязательно будем делать постмортемы и реализовывать точки роста по мотивам. И постараемся пользоваться возможностями, которые есть у вовлечённой команды.

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

Открытый курс молодого бойца по Интернету вещей

31.05.2021 12:16:05 | Автор: admin

Всем привет!

Некоторое время назад мы с партнерами IT Академии Samsung запустили открытый онлайн-лекторий Samsung Innovation Campus по Интернету вещей. В видеолекциях для студентов и новичков мы решили дать правильное, с нашей точки зрения, представление об этой сфере. И это не про обывательское представление о том, что Интернет вещей - это умные чайники и говорящие холодильники и не про пафос цифровизации и мировых перспектив Индустрии 4.0 (тут без нас много сказано). Это про то, что Интернет вещей - это серьезная промышленная область с по-настоящему сложными, масштабными задачами.

О чем были прошедшие еженедельные лекции (записи доступны в YouTube), и о чем еще хотим рассказать в рамках этого небольшого открытого образовательного проекта, читайте под катом.

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

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

Нам более близка позиция организаторов конференции InoThings++, которая проходила в течение двух лет в 2018-2019 годах (записи выступлений спикеров здесь в свободном доступе на YouTube): каждый доклад раскрывал бизнес-, либо технологическую сторону Интернета вещей в России, а иногда и то, и другое вместе. Спикеры тщательно отбирались и были с конкретным опытом: сами участвовали в разработке и внедрении решений. Однако эти материалы сложны для новичков. Они рассчитаны на подготовленную аудиторию, которая не просто владеет терминологией, но и имеет представление о затрагиваемых технологиях. А есть ли что-то более простого уровня?

Samsung с 2017 года реализует образовательный проект IT Академия, в котором есть трек по Интернету вещей. Это годовой практико-ориентированный курс для студентов вузов-партнеров проекта, который состоит в основном из учебных кейсов и лабораторных работ. На данный момент среди партнеров - 22 вуза по всей России. Однако нам то и дело задают вопрос: как принять участие в проекте, если я - не студент вуза-партнера?

Концепция лектория

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

1. По компонентам системы,

2. По навыкам: железо, софт, обработка данных,

3. По проектной работе и сферам, которые must-have, но они надпроектные (например, безопасность, дизайн, стандартизация).

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

Мы решили охватить примерно такой круг тем в следующем порядке:

  1. Общий обзор систем IoT

  2. Оконечные устройства

  3. Транспортные сети

  4. Программная часть

  5. Облачные технологии

  6. Жизненный цикл проекта

  7. Безопасность

  8. Дизайн и UX

  9. Data Science

  10. Стандартизация

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

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

Курс лекций

Все лекции доступны для просмотра в плейлисте Samsung Innovation Campus IoT Lectorium.

Лекция 1. Архитектура и типология систем IoT. Антон Куропятник (Woodenshark), Ксения Сизова (Red Bees)

Первую лекцию учебного курса вели Антон Куропятник, старший продукт-менеджер в компании Woodenshark (IoT R&D), и Ксения Сизова, руководитель проектов в компании Red Bees (IoT R&D).

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

Лекция 2. Как выбрать технологию IoT, чтобы выжать максимум от достоинств и не страдать от минусов. Антон Куропятник (Woodenshark), Ксения Сизова (Red Bees), Юрий Сизов (RedBees)

Во второй лекции к Антону и Ксении присоединился Юрий Сизов, генеральный директор компании Red Bees.

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

Лекция 3. Инфраструктура транспортных сетей. Роман Андреев (СПбГУТ).

Изучив первые два уровня IoT-системы, мы стали двигаться дальше, и одно занятие прицельно уделили телекоммуникациям. На этой лекции у нас был специальный гость: Роман Андреев, начальник Научно-образовательного центра Беспроводные инфотелекоммуникационные сети СПБГуТ им. проф. М.А. Бонч-Бруевича - одного из немногих отраслевых телеком-вузов в стране.

В ходе лекции были рассмотрены топологии 2G/3G/4G-сетей, основные производители оборудования и функциональные блоки сети, прохождение аутентификации и вызовов в сетях связи, ядро сети и радиочасть с учетом распределения частотных ресурсов. Если вы всегда мечтали узнать, как устроена антенна изнутри, то эта лекция для вас.

Лекция 4. Программная часть IoT: о чем нужно знать помимо железа. Дмитрий Чудинов (Red Bees)

Здесь мы провели эксперимент и устроили боевое крещение для студента. А почему бы и нет? Глядишь, других этот пример вдохновит. Свой дебют в нашем лектории совершил Дмитрий Чудинов, студент 4 курса, инженер-стажер в компании Red Bees (IoT R&D), выпускник платформы IoT AM. Дмитрий продемонстрировал широкое знание существующих платформ Интернета вещей и наличие опыта работы с ними.

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

Лекция 5. Облачные технологии в решениях IoT. Кирилл Святов (УлГТУ)

Развивая тему облачных технологий, в лектории выступил Кирилл Святов, декан Факультета информационных систем и технологий УлГТУ (Ульяновск) - нашего вуза-партнера. На своей лекции Кирилл Валерьевич рассмотрел типовые архитектуры программных решений по работе с данными в IoT, технологии граничных и облачных вычислений на примере IBM Cloud. Вторая часть занятия представляла собой практикум: был реализован вариант построения службы по сбору, анализу и визуализации данных, получаемых от устройств интернета вещей с использованием code-less подхода на основе Node-RED в облачной среде IBM Cloud.

Очень полезное и очень насыщенное занятие с примером устройства - посудомоечной машины, отправляющей данные. Было объяснено многое - основы работы с IBM Cloud на примере сэмпла IBM Quickstart, продемонстрирована NoSQL база данных Cloudant с кратким комментарием о том, а в чем вообще суть этого подхода и в чем отличие от стандартных реляционных БД применительно к задачам IoT, и наконец, показан доступ к системе машинного обучения IBM Watson и работа в Jupyter Notebook. То есть проложен мостик и к другим направлениям Computer Science - у нас в IT Академии Samsung как раз есть учебный трек по AI.

Бонус: лекции о предметных областях

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

"Интеллектуальные транспортные системы Умного города", Игорь Ежков (Softline)

С концепцией Умного города нас знакомил Игорь Ежков - руководитель направления Интеллектуальных транспортных систем компании Softline. Мы давно знакомы с Игорем Геннадьевичем, однажды вместе проводили с ним хакатон по NB-IoT на радиофаке УрФУ.

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

Бонус: лекции-практикумы о технологиях

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

"Взаимодействие устройств по Bluetooth Low Energy", Олег Пехов (ТУСУР)

В Томском государственном университете систем управления и радиоэлектроники (ТУСУР) наша программа реализуется на факультете безопасности. Поэтому и неудивительно, что на лекции про BLE в рамках практикума был рассмотрен сниффер пакетов. Помимо этого, в лекции были рассмотрены принципы и особенности технологии Bluetooth Low Energy, ее отличие от классического Bluetooth, разновидности устройств и способы их подключения. Лекцию вел Олег Пехов, старший преподаватель кафедры комплексной информационной безопасности электронно-вычислительных систем.

"Платформа SmartThings для Умного дома", Татьяна Волкова (Исследовательский центр Samsung)

Автор этого текста тоже приняла участие в лектории. Я решила показать в стриме, как интегрировать ваше собственное устройство в платформу умного дома Samsung SmartThings. Устройство очень простое - умный светильник на базе ESP8266, подключаемый к платформе по WiFi. Звучит несложно, но занимает вся эта работа около 40 минут - нужно зарегистрировать ваше устройство внутри платформы, скомпилировать и загрузить прошивку, настроить схему авторизации устройства, сделать обмен ключами. Тут получился целый триллер. Не всё сработало с первого раза, но всё-таки заработало.

Дальнейшие планы

На данный момент наш лекторий находится примерно посередине. Какие лекции еще мы запланировали:

  1. Экономика IoT-системы по состоянию на 2021

  2. Жизненный цикл IoT-проекта

  3. Кибербезопасность в IoT: примеры эксплоитов

  4. Как известно, в аббревиатуре IoT буква S обозначает безопасность

  5. Дизайн и UX в IoT-решениях

  6. Краш-тест вашего IoT-проекта: оцениваем идею на жизнеспособность

  7. Есть ли жизнь после релиза? Обслуживание IoT-системы

  8. Data Science в IoT

  9. Сертификация в IoT: стандарты, регуляторика и прочее

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

Какие еще важные темы мы не затронули? Чего не хватает в этом тематическом плане? Пишите в комментариях ваши предложения - как бы вы составили идеальную программу лектория по Интернету вещей для начинающих?

Смотрите лекции в рамках стримов на YouTube-канале IT Академии Samsung и смотрите архив в плейлисте Samsung Innovation Campus IoT Lectorium. Задавайте вопросы нашим лекторам, пишите свои комментарии. А может быть, вы сами хотели бы выступить с лекцией по своей теме, которая пока не озвучена - мы готовы предоставить вам слово!

Татьяна Волкова, куратор трека по Интернету вещей социально-образовательной программы для вузов IT Академия Samsung

Подробнее..

Всё о проекте Спутниковый интернет Starlink. Часть 17. Второе поколение Starlink

19.11.2020 12:06:35 | Автор: admin
Предлагаю ознакомиться с ранее размещенными материалами по проекту Starlink (SL):

Часть 1. Рождение проекта Часть 2. Сеть SL Часть 3. Наземный комплекс Часть 4. Абонентский терминал Часть 5. Состояние группировки SL и закрытое бета-тестирование Часть 6. Бета-тестирование и сервис для абонентов Часть 7. Пропускная способность сети SL и программа RDOF Часть 8. Монтаж и включение абонентского терминала Часть 9. Сервис на рынках вне США Часть 10. SL и Пентагон Часть 11. SL и астрономы Часть 12. Проблемы космического мусора Часть 13. Спутниковая задержка в сети и доступ к радиочастотному спектру Часть 14. Межспутниковые каналы связи Часть 15. Правила предоставления услуг Часть 16. SL и погода


Starlink-2.0. Второе поколение системы.



Здесь речь пойдет о новом раунде подачи заявок на использование частотного ресурса на территории США спутниковыми сетями на низкой и средней орбите. Ранее опубликованная в ЖЖ часть посвящалась прежде всего OneWEB и Телесат. Желательно начать чтение с нее, дабы понимать картину в целом, а сегодня рассмотрим заявку SpaceX.

Что попросил SpaceX в своей новой заявке в Федеральную Комиссию по связи в США?

Прежде всего заявку отличает то, что если OneWEB и Телесат просто масштабировали свои сети (банально увеличив количество ИСЗ в 5..13 раз, не меняя, по большому счету, ни частотный диапазон, ни орбиты, и не вдаваясь практически ни в какие детали), то у SpaceX это реально НОВАЯ заявка, а не просто больше таких же спутников.

И SpaceX справедливо говорит в ней о Gen2 (втором поколении системы).

Итак вот таблица с параметрами сети Starlink-2.


Если представить себе это на орбите то будет выглядеть так:

Что нового?

1. В отличие от первого поколения, абонентский терминал в Gen2 будет работать не только в Кu (11/14 Гигагерц), но и в Ка (18/30 Гигагерц). При этом абонентские терминалы для первого поколения будут работать и с ИСЗ второго поколения.

Вот частоты первого поколения Starlink:


А вот частоты для StarLink Gen2:


Что это дает?? Дает больше пропускной способности. Кu-диапазон делится на 2 части для сервисов BSS Broadcast Satellite Service (телевизионное вещание) и FSS Fixed Satellite Service (спутниковая связь), это в сумме от 10 700 МГц до 12 700 МГц. Итого 2000 Мегагерц по направлению от ИСЗ к абоненту. В Gen 2 к 2000 МГц в Кu добавится еще и 1800 Мгц в Ка-диапазоне.

2. Для того, чтобы поднять с Земли на спутник вдвое больше информации SpaceX решил использовать на гейтвеях новый никогда ранее не использовавшийся в спутниковой связи Е- диапазон частот это 81-86 Гигагерц (или 71-76 Гигагерц в обратном направлении). Здесь для Fixed Satellite Service (спутниковая связь) можно использовать не 500 МГц как в Кu, а в 10 раз больше 5000 МГц. Надо отметить, что сейчас в США этот диапазон используется только для организации наземных РРЛ (радиорелейных линий) радиомостов (радиоканалов между вышками), всего в США всего лишь около 19000 таких устройств. SpaceX должна выбирать места для своих гейтвеев так, чтобы не ставить помехи этим радиомостам.

3. По сравнению с первым поколением ИСЗ, на каждом из которых возможна работа 8 отдельных лучей от ИСЗ в сторону Земли, на втором поколении их будет больше (30 лучей, работающих на прием (из них 2 луча для управления и телеметрии) и 32 луча на передачу (2 телеметрия и управления)). Это количество сервисных лучей делится на фидерные (между ИСЗ и гейтвеем) и сервисные (между ИСЗ и абонентским терминалом).

Благодаря этому каждый ИСЗ второго поколения будет иметь в 3 (три) раза больше пропускной способности, чем спутник первого поколения.

Что еще интересное можно найти в их заявке:

4. Абонентский терминал может принимать сигнал нескольких отдельных лучей суммарной пропускной способностью до 2000 МГц (эквивалентная скорость не менее 6 Гигабит ) и передавать в полосе до 125 МГц (эквивалентная скорость не менее 125 Мбит).

5. SpaceX сообщает, что достигла соглашения с Правительственными агентствами США (в том числе и Министерством Обороны) о совместном использовании Ка-диапазона, и уверена, что сможет достичь соглашения и для использования этого диапазона спутниками Gen2.

6. SpaceX еще не подготовила и не передала в ФСС информацию о системе Starlink 2-го поколения, которую необходимо сообщить в Международный Союз Электросвязи. Это будет сделано в подходящее для этого время и SpaceX готова оплатить все расходы, связанные с публикацией данных о своей системе в каталоге МСЭ.

7. В каждом пуске ИСЗ Starlink SpaceX использует по 4 сборки для крепления ИСЗ под обтекателем, каждая сборка состоит из 2 алюминиевых легких штанг длиной 6 метров диаметром 1,5 дюйма. Время жизни этих штанг на орбите не более 36 дней, а вероятность столкновения с любым другим объектом равна 0.00000000653.

8. Для защиты от космического мусора и микрометеоритов все важные элементы ИСЗ защищены алюминиевым экраном толщиной 1 мм. При этом, даже если экран и баки с Криптоном будут пробиты, это не вызовет взрыва и образования обломков диаметром более 1 мм.

9. Многие из бортовых приемников командной радиолинии, передатчиков телеметрии и электроники, управляющей ИСЗ, резервированы для предотвращения потери управления ИСЗ в полете. Расчеты по собственной методике SpaceX показывают, что вероятность потери управления ИСЗ из-за столкновения с космическим мусором диаметром более 1 мм составляет 0.000776 за весь период работы ИСЗ.

10. SpaceX будет мониторить топливные танки и аккумуляторы во время работы и не будет разряжать топливные танки и батареи по окончании работы. SpaceX планирует направлять ИСЗ в атмосферу для полного сгорания в работающем состоянии, считая это наиболее безопасным вариантом предотвращения создания космического мусора.

11. SpaceX будет постоянно мониторить орбиты своих ИСЗ и рассчитывать вероятность их столкновения с известными объектами космического мусора и других ИСЗ. Если вероятность столкновения будет больше 0,001% будет предприниматься маневр ИСЗ Starlink с изменением его орбиты на безопасную
12. ИСЗ Starlink используют GPS и другие сенсоры для определения своего местоположения.

13. SpaceX обязуется координировать движение своих ИСЗ со всеми другими НГСО системами, подавшими заявки в ФСС, в том числе с Куйпер (его высоты 590, 610 и 630 км), а также другими неамериканскими 54 группировками и отдельными ИСЗ, работающими/пересекающими эти высоты, зарегистрированными в каталоге МСЭ.


меня поразило количество стран, имеющих спутники на этой орбите (или заявки в МСЭ на размещение ИСЗ там)

14. ИСЗ системы Starlink будет полностью сгорать в атмосфере, и частицы, достигшие поверхности Земли, будут иметь энергию не более 15 Джоулей, то есть риск травмы для человека равен нулю.

15. Спутники 2-го поколения будут иметь штатные межспутниковые каналы связи.

16. Типовая задержка составит не более 50 миллисекунд.

17. Размещение ИСЗ на орбитах 360 км обеспечит то, что спутник в случае его неисправности будет освобождать орбиту (сгорать в атмосфере) всего лишь за три месяца.

18. Благодаря пункту выше, орбиты высотой 360 км одни из самых чистых и вероятность столкновения ИСЗ на ней в 21000 раз меньше, чем на орбите высотой 800 км.

19. Для уменьшения помех в астрономических наблюдениях, спутники второго поколения будут: во-первых, поворачиваться вокруг своей оси в момент движения на рабочую орбиту, а во-вторых, их Солнечные Батареи складываться особым образом. Обе эти меры позволят обеспечить, что время, когда поезд из запущенных ИСЗ может быть замечен наблюдателем с Земли (без телескопа), менее недели. Еще на этих ИСЗ будет использовано специальное покрытие по уменьшению Альбедо на 55% и козырек для солнечного света. Также меньшая высота орбиты спутников 2-го поколения обеспечит, что они будут быстрее покидать угол наблюдения Астрономами, чем ИСЗ, находящиеся на более высоких орбитах.

20. Абонентский терминал будет крайне прост для включения и оно будет состоять из 2 шагов: навести на небо и включить его.

21. Благодаря большому числу ИСЗ на видимом для абонентского терминала участке неба, терминал сможет выбирать для работы те ИСЗ, которые незатенены для него деревьями или более высокими домами, то есть система получит очень высокую гибкость. Кроме того, система 2-го поколения, будет обладать Искусственным Интеллектом, позволяющим ей отключать/выбирать для работы с конкретным абонентом те лучи/ИСЗ, которые не ставят помехи другим системам на низкой или геостационарной орбите.

Вот в целом и все. Как я понял, общая цель создания спутниковой сети Starlink второго поколения обеспечить пользователю уровень сервиса (в части задержки и скорости) на уровне того, который имеют сейчас жители мегаполисов в США, сидящие на оптике или будущей сотовой сети 5G.

Если говорить о практической реализации, то кроме вопроса управления и координации всей группировкой, остальное не кажется крайне сложным, но требует огромных инвестиций и может иметь право на реализацию, только в случае коммерческого успеха в США сети Starlink первого поколения. При этом на сегодня однозначно нет 100% гарантии такого успеха.
Подробнее..

Разбор почему SoftBank планирует продать акции телеком-гиганта T-Mobile на 21 млрд

14.07.2020 16:07:05 | Автор: admin


По данным СМИ, японской конгломерат SoftBank планирует продать 198 млн акций американского телеком-гиганта T-Mobile за примерно $21 млрд. Это примерно равняется 65% всей доли SoftBank в компании, чьи акции стабильно растут на протяжение последних месяцев. В нашей новой статье разбираемся в причинах этой сделки.

Зачем SoftBank продавать акции


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

Так, входящий в SoftBank фонд Vision Fund на $100 млрд, инвестировал в WeWork эта компания не смогла выйти на биржу после скандала, в центре которого оказался ее основатель Адам Нейман он выстроил непрозрачную корпоративную структуру и не приблизился к выходу в прибыль. Карантинные меры также серьезно ударили по бизнесу Uber еще одной портфельной компании Vision Fund. В итоге, SoftBank отчиталась о потерях в $17,7 млрд.

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

Планы


Как сообщалось ранее, SoftBank планирует продать активов на сумму в $41 млрд. Деньги пойдут на обратный выкуп акций и сокращение долговой нагрузки.

T-Mobile же планирует выпустить часть проданных SoftBank акций в обращение на биржу. В России акции T-Mobile можно купить на Санкт-Петербургской бирже для этого не нужно открывать счет у иностранного брокера, достаточно будет российского счета. Открыть его можно онлайн.

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:


Подробнее..

От Oracle до Tarantool и Hazelcast современный BSSOSS для телекома

20.07.2020 20:10:45 | Автор: admin
Эту статью можно рассматривать как один из частных случаев нашего способа принимать решения о разработке и развития продуктов. Если вам интересна тема выбора, какие фичи и в каком приоритете нужно реализовать в своем продукте, то рекомендуем к прочтению Как мы выбираем идеи для развития своих продуктов: вендор должен уметь слышать.

Начинаем с Oracle


С самого начала Forward Billing использовал в качестве СУБД решения Oracle. С учетом давности начала разработки продукта это было фактически единственным верным решением по выбору базы данных.

Упрощенная техническая схема работы Forward Billing (БД, сервер приложений, веб-сервер, веб-браузер клиента) со стрелочками между элементами, показывающая взаимосвязи. Надо отрисовать дизайнеру в стилистике Форварда. Указать на картинке год, когда Forward Billing только появился, чтобы не было сомнений о том, что это начальная схема работы.


A long time ago in a galaxy far far away

Даже сейчас, по прошествии 14 лет, Oracle является основной СУБД нашего биллинга и используется для хранения всей учётной и регламентированной информации.

Однако эволюция превратила биллинговую систему в линейку BSS/OSS из 16 продуктов, которые полностью закрывают оператору связи все его потребности от CRM и PRM и до Service Provisioning и DMP. Появились клиенты обслуживающие многомиллионные базы абонентов, изменился сам рынок. И использование только Oracle перестало соответствовать бизнес-требованиям современных компаний.

Скорость и деньги


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

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

Есть три основных фактора, на которые мы смотрим при отборе технологий для расширения своего рабочего стека и внедрения в продуктовую линейку:
  • Технологический скорость и надежность работы, текущий опыт использования.
  • Стоимость владения покупка лицензий, персонал (включая поиск и найм специалистов для нас, как разработчиков, и для клиента, в качестве in-house специалистов).
  • Перспективность как долго технология существует, кто её разрабатывает, в каких проектах используется и насколько вероятно, что разработчик/владелец технологии в 5-летний срок прекратит развитие.


Оценивая эти факторы, мы сформировали для себя набор из Oracle, PostgreSQL, Hazelcast и Tarantool, которые применяем сейчас.

Oracle основа крупных и ответственных проектов, долговременное целостное хранение и обработка агрегированных данных.

PostgreSQL Заинтересованность в использовании PostgreSQL выказывают сейчас компании с государственным участием. Но крупные наши клиенты банки, крупные операторы скорее пока не готовы рассматривать эту СУБД в качестве основной. Тематика PostgreSQL сейчас на слуху, многие интересуются, обсуждают, просчитывают различные варианты. Для работы с госсектором и с аффилированными им организациями это бесспорно основной на текущий момент вариант замены Oracle.

Анекдот в качестве картинки:


Tarantool сейчас используется как одна из основных компонент Forward OSS. Нами запланировано на 2020-2021 годы миграция на Tarantool, еще пары систем из нашей линейки продуктов. Мы видим хорошую точку роста за счет вынесения подсистемы на отдельную быструю БД. Пока не все из наших заказчиков воспринимают Tarantool, как достаточно серьезную технологию, но здесь лучший аргумент За это успешные результаты промышленной эксплуатации. Так что время покажет оправдает ли себя Tarantool.


Hazelcast для перемалывания больших объемов данных на лету и последующей передачи результатов расчетов в биллинговую систему. Мы используем Hazelcast в Forward Fusion это система онлайн-тарификации используемая для предоставления услуг по препейд модели и в Forward PC (продакт каталог) это инструмент разработки и управления маркетинговыми активностями компании позволяющий формировать пакеты предложений в режиме реального времени. Среди российских вендоров мы одни из первых начали применять эту технологию. Большинство препейдных систем, эксплуатирующихся в России, разработаны еще лет 10 назад, у них другой технологический стек и они медленнее и тяжелее нашего решения. Нам Hazelcast нравится, потому что:
  1. Хорошо горизонтально масштабируется, удобно кластеризуется.
  2. Дает достаточно хорошую отказоустойчивость, когда его используешь в кластере из трех элементов.
  3. Удобно наращивается нодами. У нас шаг от 500 тыс. до 1 миллиона абонентов на одну ноду.




Реальные предпосылки


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

Вообще, надо здесь пояснить нашу позицию по вводу новых технологий в платформу Forward. Мы коммерческая организация и не можем позволить себе безлимитно тратить время на непрерывное изучение и опробирование всех новых технологий подряд, ресурсы R&D ограничены. Наша задача внимательно прислушиваться к рынку и своим сотрудникам. Если проскальзывает перспективная на первый взгляд технология, то делается обзор схожих по классу решений. Смотрим на:
  • Стоимость разработки.
  • Стоимость эксплуатации.
  • Сложность обслуживания.

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

С другой стороны, опыт работы с зарубежными клиентами говорит, что там от нас ждут Oracle. Да, если мы анонсируем, что дополнительно работаем с Hazelcast и Tarantool, то это может быть воспринято, как какой-то дополнительный плюс, но в первую очередь Oracle.

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

Сейчас есть рыночный тренд и некое общее нагнетание атмосферы ухода на нереляционные базы данных, отказа от политик лицензирования, использование бесплатного ПО, отказ от тяжелых проприетарных решений. Рынок даже в лице некоторых крупных компаний хочет на уровне политики закупок работать со свободно-распространяемым ПО в попытке экономить. Однако все старые информационные системы не обновятся в мгновение ока, не перейдут на новые технологии. Поэтому мы по сторонам смотрим, новые технологические решения постепенно в платформу вводим, но и об Oracle забывать не будем. Возможно, через 5 лет перечень используемых СУБД существенно обновится, но в перспективе 2 лет каких-то существенных изменений мы не ожидаем.

Мы новые технологии стараемся в первую очередь применять при запуске новых продуктов или при выделении каких-то подсистем в отдельные решения.
В наших SaaS-решениях новые СУБД использовать проще, потому что мы полностью контролируем окружение. Поэтому там процесс миграции на новые более простые и дешевые в эксплуатации СУБД идет быстрее. Экономический фактор решает никто не хочет платить лишнее за лицензии.

Tarantool & Hazelcast результаты расширения стека технологий Forward Telecom


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

Повышение технических компетенций помогает нам и в разработке новых модулей для Forward Billing. Например, тех, что требуют перемалывать огромные массивы постоянно обновляемых данных по профилям пользователей, поиску Next Best Offer (NBO), срабатыванию автоматизированных триггеров и бонусных аккумуляторов и т.д.

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

Если у вас есть опыт применения Tarantool и Hazelcast в телекоме, биллинговых или учетных системах, вы хотите поделиться знаниями оставляйте комментарии к статье. Спасибо за внимание!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru